❗The functionality described in this article won't be available until the full feature release.
You will probably have several Conditional Policies that apply in different use cases.
In order to ensure that Policy A doesn't overrule Policy B when Policy B is a better fit, you'll need to Prioritize them via drag and drop.
In this article, we'll explore how to properly Prioritize Policies for Conditional Access Reviews, Conditional Approver Groups, and Conditional Onboarding Success Targets to ensure that you have the correct setup for complex conditional flows.
📋 Prerequisites
In order to replicate the actions shown in this article, you must:
Have a full understanding of the Conditional Policy Flow
Have successfully set up Condition Packages
📊 Prioritization Logic
When a new Request is created, the system determines which Conditional Policy should be applied. If none of them resolve as True, the Default Settings are applied.
Let's take a look at how this logic works for Conditional Approver Groups:
A new Guest Request is created, and the system needs to determine which Approver Group should be responsible for it.
In order to determine which Conditional Approver Group the request should be sent to, the system sequentially checks all Conditional Approver Group Settings (in the prioritized order).
The first Conditional Approver Group Setting, for which a linked Condition Package resolves True, is applied. If none of the Conditional Approver Group Settings resolve as True, the default Approver Group Setting is applied.
Let's explore a concrete example:
1. A new Guest-Request is created
2. The system checks if 'Conditional Approver Group 1' should be used for this Request
The system checks 'Condition Package 1' → Resolves FALSE ❌
The system checks 'Condition Package 3' → Resolves FALSE ❌
None of the connected Condition Packages resolved TRUE, therefore 'Conditional Approver Group 1' is NOT used. ❌
3. The system checks if 'Conditional Approver Group 2' should be used for the Request
The system checks 'Condition Package 2' → Resolves TRUE ✅
At least one of the connected Condition Packages resolved TRUE, therefore 'Conditional Approver Group 2' is used! ✅
4. Since 'Conditional Approver Group 2' is used, the Default Approver Group is not used.
(If 'Condition Package 2' hadn't resolved TRUE, the Default Approver Group would've been used instead)
💡 Even though this example concentrates on Conditional Approver Groups, the same logic applies across all other Conditional Policies.
💡 Conditional Onboarding Media is the only exception to this rule since its behavior is additive instead of exclusionary.
All Onboarding Media for which a Condition Package resolves true is shown to the Guest, while Media for which a Condition Package doesn't resolve true is not.
✨ Improving Prioritization
The numerical placement of your Policies is extremely important because if one of them gets applied, the next ones aren't checked, which can result in a less suitable Policy being applied to your Team.
Let's use three different Conditional Policies as an example:
Policy Setting 1 - The Conditional Package for this Policy states that the Team Name must contain the word "Confidential".
Policy Setting 2 - The Conditional Package for this Policy states that the Team Name must contain the word "Confidential", and the Team Sensitivity Label must be "Highly Confidential".
Policy Setting 3 - The Conditional Package for this Policy states that the Team Name must contain the word "Confidential", the Sensitivity Label must be "Highly Confidential", and the Group ID must equal "8f3c2a41-9b7e-4d2a-b6a4-3e5c9d1f7a42".
The Team that we're creating a Request for has the following characteristics:
Team Name = Confidential
Sensitivity Label = Highly Confidential
Group ID = 8f3c2a41-9b7e-4d2a-b6a4-3e5c9d1f7a42
Here's what happens when we create a Guest Request for this Team.
As you can see, even though Policy 3 is a perfect match for this Request, it didn't even get checked, because the first Policy Setting resolved True and got applied.
But we can easily fix this scenario by reversing the order in which Policies are arranged.
Here's what happens when we make a Request for the same Team, but the Policy Setting order is:
Policy Setting 3 - The Conditional Package for this Policy states that the Team Name must contain the word "Confidential", the Sensitivity Label must be "Highly Confidential", and the Group ID must equal "8f3c2a41-9b7e-4d2a-b6a4-3e5c9d1f7a42".
Policy Setting 2 - The Conditional Package for this Policy states that the Team Name must contain the word "Confidential", and the Team Sensitivity Label must be "Highly Confidential".
Policy Setting 1 - The Conditional Package for this Policy states that the Team Name must contain the word "Confidential".
As you can see, since Policy Setting 3 was the first on the list, it has resolved True, and now the most suitable Settings for the Team have been applied.
💡 The best practice is to always order your Policies from Most to Least exclusive.
This way, more exclusive Condition Packages have the opportunity to resolve True, without running the risk of more inclusive Packages that only partially match the best fit, eliminating them from consideration.
👣 Next Steps
Now that you understand the best way to prioritize your Conditional Policies, it's time to explore individual Conditional Governance Settings:
⛑️ Need more help?
Get further assistance with External User Manager through our support chat widget within the app, or reach out to us at [email protected]