Can request
Can request is the effect that puts something in somebody's access catalog. Its own words in the builder: "They can ask for it. This policy's ladder decides who approves." It grants nothing on its own, so activating one moves no access anywhere. Somebody still has to ask.
Auto approve
A single toggle. On, it reads "Approved the moment they ask. Nobody has to sign off." Off, it reads "Requires approval. The ladder below decides who signs off." A policy can auto-approve or route through stages, never both.
The approval ladder
Numbered stages, worked through in order. Each stage needs an approver pool and a stage name, and can carry a message and its own self-review setting, which starts barred so a requester cannot sign off their own request. Use Add approval stage to add a rung.
An empty ladder is a valid, deliberate choice. It reads "No approval ladder set. Falls back to the resource's own approvers." Ploy will tell you if a stage is half-finished: "Each approval stage needs an approver pool and a stage name", "Each approval stage's self-review setting must be on or off", "An approval ladder needs at least one approval stage".
Terms
Three independent rows, each optional.
Maximum duration: an amount and a unit (minute, hour, day, week, month or year), or Indefinite.
Extensions: whether the requester can extend, and how long before expiry to remind them.
Reason: whether the requester has to say why.
They compose into the tail of the sentence, so a finished policy reads like "Everyone can request Slack for up to 3 months at a time, not extendable, no reason required."
A term you leave alone stays silent, and the resource's own setting applies instead. Setting one and not the others is normal: you are overriding just that knob.
Which policy decides a request
Several policies can reach the same person and the same app. The order is fixed, and nothing about which policy you wrote first matters. For example, if we had different policies all covering the same resource on an access catalog:
A Can't request policy composes first and refuses the request outright.
Otherwise, if one is auto approve and one requires approval, auto approve wins.
Among ladders, the fewest stages wins.
If two ladders are still tied, the older policy wins.
If a Can request policy matched but carries no usable ladder, the resource's own approvers decide.
If no policy names the resource at all, the request is decided by Resource's own approval policy, which is what the request's own details will say.
The overlaps card in the builder and the drawer spells each of these out for real numbers, for example "453 shared people take its 1-step path instead, as the older policy. No conflict." and "8 shared people are approved automatically instead. No conflict."
What the preview shows
For a request policy, the preview compares the answer a request would get before and after, not who holds what. People move because the policy now routes their request, because they are newly auto-approved, because the route changed, because they are newly refused, or because the terms changed. Anyone another policy already refuses shows as blocked.
After you activate
The policy drawer gains a Requests tab headed "Requests this policy decided." Until somebody asks, it reads "No requests decided by this policy yet." Every decided request also carries a Policy link in the Access Requests table and in a request's own details, which opens this policy.
Good to know
Can request can target Everything, which is how an org-wide request floor is written.
Luna's starter playbook proposes 90 days with extensions allowed for everyday on-request access, and tighter terms for sensitive apps: 30 days and a reason required.
A Never gets policy over the same people beats this one. They can ask, but they could never hold it, and the overlaps card flags that as a real conflict.