Patch approval hierarchy

Patch approvals ensure that the patches a device is looking for or wants to download is legitimate and will not cause any issues or conflicts. Conflicts can occur when devices belong in multiple patching rules. When conflicting patch approval statuses are applied to a device from either a rule or a device level approval, precedence is given according to strict approval hierarchies outlined in the table below. It is best to have devices using only one rule.

An example of when the patch approval hierarchy can take place is when a device at the customer level belongs in two different rules. Rule 1 permits the installation of Patching Widget software, while in rule 2 declines the installation of the same patch.

For more information see Approving and declining patches manually.

Level Order
1	Device
2	Site
3	Customer
4	Service Organization
Status Order
1	Declined
2	Approved for Install
3	Approved for Removal
4	Not Approved
5	No Approval

Therefore, Declined at Device is the highest status in the approval hierarchy, No Approval at Service Organization is the lowest.

For example:

• A patch is Declined at the Service Organization level and Approved for install at the Customer level - Approved for Install at the Customer level takes precedence.
• A patch is Declined at the Customer level and Approved for Install at the Customer level - Declined at Customer level takes precedence.

Approval Hierarchy

A single patch may have a large number of approvals depending on different targeting criteria. The priority process for approvals is as follows:

1. Device Specific

2. Site Specific Rule Targeted

3. Site Specific no rule target

4. Customer Specific Rule Targeted

5. Customer Specific no rule target

6. SO Specific Rule Targeted

7. SO Specific no rule targeted

8. System level

If there are conflicting approvals at the same level, the priority is:

1. Declined

2. Approved for Install

3. Approved for Removal

4. Not Approved = No Approval (pre-12.1)

5. Not Approved (post-12.1)