The six effects at a glance
The effect is the verb in a policy's sentence. There are six, and the effect you pick decides which other settings the builder offers you.
Gets
"Ploy grants this access and keeps it true from then on."
Everyone the policy matches should hold the target. Anyone who does not hold it yet becomes access Ploy owes them, and it is provisioned through that app's own provisioning strategy, on the same path a manual grant takes. Someone who stops matching stops being covered, and their access is offered for removal according to the enforcement you chose. By default we set this to suggested which means Ploy won't automatically remove the access but will alert and suggest to admins that it is removed.
Never gets
"Ploy denies this access and surfaces anyone who has it."
A standing refusal. A refusal always beats a grant, so if one policy grants an app to a group and another refuses it to some of those people, the refused people do not get it. Anyone already holding it is surfaced for you to deal with.
Can request
"They can ask for it. This policy's ladder decides who approves."
This effect hands out nothing on its own. It makes the target requestable and sets the approval ladder and the terms: how long a grant lasts, whether it can be extended, and whether a reason is required. Turn Auto approve on and the request is approved the moment it is made. Leave the ladder empty and the request falls back to the resource's own approvers.
Can't request
"Hidden from their access catalog, and asking is refused."
The deny of the request side. The target disappears from those people's catalog, and a direct request is refused. It composes before any Can request policy, so it wins over a ladder.
Must satisfy
"Holding this access requires these conditions. Ploy acts on anyone who stops meeting them."
A standing requirement attached to access some other policy hands out, such as multi-factor authentication being on. It never grants or withholds access itself, so it never competes with another policy. It needs at least one condition before you can save it, and if two Must satisfy policies cover the same people, both sets of conditions have to be met.
Remove when unused
"Ploy removes this access once it has gone a set number of days without being used."
A continuous cleanup. You set a number of days without use, 60 by default, and Ploy acts once access passes it. This effect has its own two-word enforcement pair instead of the usual three: Suggest removal, where a person approves each removal, or Remove automatically.
The six side by side
Effect | Moves access? | Enforcement | Manual overrides | Its own settings |
|---|---|---|---|---|
Gets | Yes, grants | Yes | Yes | None |
Never gets | Yes, removes | Yes | Yes | None |
Can request | No | No | No | Ladder, auto approve, terms |
Can't request | No | No | No | None |
Must satisfy | No | No | No | Conditions (required) |
Remove when unused | Yes, removes | Suggest removal or Remove automatically | No | Days without use |
Good to know
The precedence is fixed: a refusal beats a grant, a refusal beats permission to ask, and refusing the ask beats permission to ask. Must satisfy does not compete, it attaches to whatever the other policies produce.
Enforcement is not offered on Can request or Can't request, because a request policy holds no access to enforce against.
Manual overrides are not offered on the request pair, or on Remove when unused.
Remove when unused cannot suspend access instead of removing it. Ploy refuses that combination.
Only the deny and request effects can target Everything. Gets, Must satisfy and Remove when unused must each name a specific app or permission.