FAQ
The questions that come up most often when a team starts writing access policies, answered in a few sentences each, with a pointer to the article that covers the detail.
The basics
What is the difference between a policy and a resource's own approval settings?
A resource's access configuration decides what happens for that one resource. A policy is a standing statement about a population, so it covers the person who joins that department next month without anybody editing anything. When no policy names a resource, its own settings still decide, and a request shows "Resource's own approval policy". See What an access policy is.
If I write a Gets policy, does it grant access straight away?
Yes, once it is active. Saving with Create & activate starts a pass within seconds, and Ploy provisions the access through the resource's provisioning strategy. If you want to look before anything moves, save it disabled first, read the preview, then activate. See Gets.
My policy says Active but nobody has the access yet. Why?
The access is most likely awaiting provisioning: the policy has asked for it, and it has not been created in the app yet. That can be waiting on a batch approval, on the resource's provisioning being set up, or simply on the next pass. Check the Awaiting provisioning section of the coverage ledger. See Suggested removals and expiring access.
How long does a newly active policy take to provision access?
Seconds, in the normal case, because a save starts its own pass immediately. Anything that pass misses is picked up by a safety sweep that runs every 15 minutes. See Thresholds and defaults.
Can a regular employee see our policies?
No. Policies are an admin surface, and the same permission gates the Policies tab and Luna, so an employee asking Luna about policies gets the same refusal the page would give them. Employees only ever meet the outcome: what is in their access catalog, what terms a request carries, and whether an ask is refused. See How policies fit with the rest of Ploy.
When policies meet each other
What happens if two policies disagree about the same person and the same app?
Nothing about which policy you wrote first matters. A refusal beats a grant, refusing the ask beats permission to ask, and a condition attaches to whatever the other policy produces rather than competing with it. When two Can request policies both apply, automatic approval wins, then the shorter ladder, then the older policy. See Overlaps and precedence.
Does a Never gets policy always win? Is there any way round it?
Yes, it always wins over a grant for the people both policies reach. The only way through is an exception, which is a carve out tied to that one deny. See Never gets.
What is an exception, and how is it different from editing the deny?
An exception punches through one specific deny for a named sub population, and nothing else. Editing the deny changes it for everyone it covers. Access explained only by an exception gets its own slice in the coverage ledger, so you can always see how much of your estate rests on carve outs. See Overlaps and precedence.
Can somebody request access to a resource no policy covers?
Yes. When no request policy names a resource, the resource's own approval settings decide, exactly as they did before you wrote any policy. See Can request.
Enforcement and manual changes
What is the difference between enforcement and manual overrides?
Enforcement is how firmly Ploy acts on what it finds by itself: Suggest only, Auto-suspend or Auto-revoke. Manual overrides are how the policy reacts when a person changes access by hand against it: Reverse, Flag or Log. Two settings, two different triggers. See Enforcement and manual overrides.
What does Suggest only actually do?
It records what the policy would change and puts it in the suggested removals queue for a person to decide. Nothing is removed until somebody approves it. It is the default, and it never triggers the confirmation gate. See Enforcement and manual overrides.
What do Reverse, Flag and Log do in practice?
Reverse puts access back the way the policy says and shows you what happened. Flag lets the change stand and shows it to you on the policy's Overridden tab. Log lets the change stand and records it in history without telling anyone. Flag is the default. See Overrides.
If I manually revoke access a policy grants, what happens next time the policy runs?
That depends on the manual overrides setting. With Flag, the removal stands and appears on the Overridden tab for review. With Reverse, Ploy re-grants it. With Log, it stands and stays quiet. See Overrides.
If I manually grant somebody access a Never gets policy forbids, does Ploy take it away?
Only if the policy is set to Reverse. Otherwise the grant stands and is flagged for you, and it shows in the coverage ledger as manually overridden. From the Overridden tab you can either restore access, which puts the policy back in force, or exempt the pair, which keeps the manual change for good. See Overrides.
Can I set a maximum length on access directly in a policy?
Not yet. A policy can remove access that goes unused, but the maximum length of access is still set on the resource. Trying to write it in a policy is refused with a message saying so. See Error and refusal messages explained.
What is the difference between how long a Gets policy's access lasts and the duration in request terms?
A Gets policy's duration bounds the access it hands out. Request terms bound what somebody may ask for on a Can request policy, including a maximum duration, whether they may extend, and whether they must give a reason. They are separate settings on separate effects. See Can request.
Saving and confirming
Why was my activation blocked with a message about affecting N people?
Because the policy enforces automatically and reaches more people than the confirmation threshold, which is 50 by default. It is a speed bump, not a refusal. Read the number, and either confirm it or go back and narrow the Who. See Preview before you save.
What happens if I do not confirm?
Nothing is saved and nothing changes. The policy stays exactly as it was, and you can edit the Who and try again. See Preview before you save.
Can we raise or lower the 50 person threshold?
It is a Ploy side setting with no control in the dashboard, so ask us if a different number suits your organisation. Writes made through the API answer it automatically. See Thresholds and defaults.
Coverage
What does Overridden mean, and how is it different from Unexplained?
Overridden is access somebody kept or granted by hand against what a policy says, so there is an explanation and a named person behind it. Unexplained is access no policy accounts for at all, which is the number to treat as "access I cannot explain to an auditor". They are deliberately separate, not folded together. See Reading the estate graph.
Why does coverage not match the number of policies I have written?
Coverage counts pieces of access, not policies. One policy can explain thousands of grants, and a hundred request policies explain none, because a request policy holds no access. The policy counts and the coverage percentage answer different questions. See Reading the estate graph.
Suggestions and the access model
What does a birthright mean, and how is it different from writing a Gets policy myself?
Birthright is the tier in the model Luna drafts for access everyone in a group simply gets. It lands as an ordinary Gets policy, so the difference is how it was chosen, not what it becomes. Ploy keeps the tier deliberately small and attribute based. See A modern access model in five minutes.
Why would Ploy never make something a birthright even if everyone holds it?
Because standing access to a sensitive app is exactly what the model exists to remove. However uniformly a sensitive app is held, it is offered as a request with tighter terms instead. See A modern access model in five minutes.
If I dismiss a suggestion, will Luna suggest it again?
No. Dismissing is a decision, and the same suggestion is suppressed afterwards. Deleting a policy is different: it is not a refusal, so the same thing can be proposed again later. See Statuses and lifecycle.
What is the difference between Dismiss and Delete?
Dismiss turns down a suggestion you never had, and stops it coming back. Delete removes a policy you do have, keeps its history, and does not stop it being suggested again. Turning a suggestion down with a written reason is a third path, and the reason is kept on the record. See Statuses and lifecycle.
What is a near miss, and why does it matter when nothing was proposed?
When Ploy has nothing confident enough to suggest for an app, it names up to three groups that came close and which floor each missed. It turns an empty answer into a starting point, usually "this group is nearly right, widen it slightly". See Let Luna draft your access model.
Can Luna activate a policy without me seeing the numbers first?
No. Luna can only acknowledge the size of a change after it has shown you the preview, and its guidance is to land a granting policy disabled, show you the impact, then activate. See Let Luna draft your access model.
Deleting and rolling out
What happens to the access people already have if I delete the policy that granted it?
It stays. It simply stops being explained by any policy, and moves into the unexplained slice of the coverage ledger. The delete dialog also offers "Also remove it", which sends that access to your approvers rather than removing anything immediately. See Statuses and lifecycle.
What is a prepared copy, and why can it not be edited?
Before request policies are switched on for your organisation, Ploy writes a copy of each resource's existing request settings as a policy so you can see and compare them. The resource's configuration is still what governs, so Ploy refuses an edit rather than accepting one it would not apply. Renaming or tagging one is always fine. See Error and refusal messages explained.
What changes for existing policies when we switch request policies on?
The prepared copies stop being a preview and start being what decides a request, and they become editable. Grant and deny policies are not affected by that switch, because they take effect as soon as your organisation has policies switched on at all. See Before you start.
API and automation
Can an API key create a policy that is still a suggestion, for a human to review later?
No. The API writes Active or Disabled only. Land it disabled if you want a person to look before it takes effect. See Thresholds and defaults.
Does an API created policy show who made it?
Not as a named person, because a key is not a person. The policy records that it came from the API instead. See Policy history and audit.
Is an update additive, or do I have to send every field?
Send every field. An update replaces the whole policy, so an omitted optional field is cleared. See Policy history and audit.
Can we manage policies as code?
Through the API, yes.