Overlaps and precedence
Policies are written independently, so sooner or later two of them will land on the same people and the same app. Ploy does not make you sort that out by hand: it has one set of precedence laws, and it shows you every overlap before and after you save.
What counts as an overlap
Two policies overlap when they name at least one of the same targets and both of their WHO filters reach at least one of the same people. Both halves are needed. Two policies about the same app but different departments do not overlap, and neither do two policies about the same department but different apps.
The order policies appear in the list decides nothing. Nothing about which policy you wrote first changes any outcome.
The precedence laws
Law | In practice |
|---|---|
A refusal beats a grant, always | Never gets beats Gets |
A refusal beats permission to ask | Never gets beats Can request |
Refusing the ask beats permission to ask | Can't request beats Can request |
Conditions do not compete, they attach | Must satisfy conditions whatever the others produce |
For grants, the result is simple arithmetic: everyone your Gets policies name, minus everyone your Never gets policies name for that same target. The only way through a refusal is an exception, and an exception punches through only the one denial it is attached to.
Two Must satisfy policies never fight. Their conditions stack, so the shared people must meet both.
When two request policies compete
This is the one case settled by a contest rather than a law. Among the request policies that match, Ploy picks in this order:
A policy that approves automatically beats any approval ladder.
Otherwise, the ladder with the fewest stages wins.
If they are still level, the older policy wins.
The drawer says which happened in plain words, for example "453 shared people are approved automatically instead. No conflict." or "453 shared people take its 1-step path instead, as the older policy. No conflict."
Where Ploy shows overlaps
On a policy card: an "Overlaps {N} policies" chip.
In the policy drawer: an Overlapping policies section, framed as "Only the shared people are affected. Everyone else follows this policy as configured."
In the builder: an Overlaps card in the preview column on the right, before you save.
On a resource's Policy tab: a Targeting this resource section, and an Org-wide denials section when any org-wide refusal reaches it.
Each overlap is described from the seat of the policy you are looking at, with the number of shared people. An overlap that changes the outcome for those people is tinted and worded plainly, for example "It refuses 445 shared people, so this policy is ignored for them."
Good to know
Most overlaps are fine. A Gets policy alongside a Can't request policy is a normal pattern, not a mistake: those people are given the access and cannot ask for it themselves. That is policy assigned access.
Watch for an open door to nothing. A Can request policy overlapping a Never gets policy lets people ask for something they could never hold. Ploy calls this out because the refusal wins in the end.
The strongest enforcement wins per person and target. Where matched policies disagree about how firmly to act, Ploy takes the strongest of Suggest only, Auto-suspend and Auto-revoke, in that order.
Org-wide policies can only refuse. The Everything target is available on Never gets and Can't request only. A policy that grants must name a specific app or entitlement.
When no request policy names an app, the app decides. The request then follows the resource's own approval policy, which is also what a request shows when no policy decided it. A Can request policy with an empty approval ladder falls back to the resource's own approvers on purpose.
A policy may not undo its own reason for existing. If you write a refusal that removes the very access it selects people by, Ploy refuses to save it: it would undo itself every lap. Pick a different target, or select people by different access.