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.
|2||Approved for Install|
|3||Approved for Removal|
Therefore, Declined at Device is the highest status in the approval hierarchy, No Approval at Service Organization is the lowest.
- 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.
A single patch may have a large number of approvals depending on different targeting criteria. The priority process for approvals is as follows:
Site Specific Rule Targeted
Site Specific no rule target
Customer Specific Rule Targeted
Customer Specific no rule target
SO Specific Rule Targeted
SO Specific no rule targeted
If there are conflicting approvals at the same level, the priority is:
Approved for Install
Approved for Removal
Not Approved = No Approval (pre-12.1)
Not Approved (post-12.1)