How policies fit with the rest of Ploy
Policies are not a separate island. They decide what your request catalog offers, what gets provisioned, and what an auditor can be shown. This article is the map.
Requests and catalogs
A Can request policy decides who may ask for a target, who approves it, and on what terms. A Can't request policy hides the target from those people's catalog and refuses a direct ask.
When no policy names a resource at all, requests for it still work: they fall back to the resource's own approval settings. You will see this named in two places. On an access request's details, the Policy field reads "Resource's own approval policy". In the builder, an empty approval ladder is valid and says so: "No approval ladder set. Falls back to the resource's own approvers."
On the Requests tab, requests that a policy decided carry a Policy link straight to that policy. Requests decided the older way carry nothing in that column.
Provisioning
A Gets policy does not talk to your apps directly. It works out who should hold what, and the access is then provisioned through that resource's own provisioning strategy, using the same call a manual grant uses. Where your organisation approves provisioning in batches, the batch waits under Settings, then Batch approvals.
If an app you are granting has no provisioning set up, the builder warns you before you save and the policy will grant nothing to anyone until you fix it.
Access reviews and audit
The Coverage ledger is the audit-facing view. It accounts for every grant a person holds in five slices: explained by policy, awaiting provisioning, exceptions, manually overridden, and unexplained. Unexplained is the number to treat as "access I cannot currently explain to an auditor". Open it from the Policy coverage card's Open the coverage ledger link.
Onboarding steps
When onboarding you no longer need to define who get's what access at what stage. As policies in Ploy are declarative state, as soon as the employee meets the conditions for getting that access (e.g. becoming active etc.) they will automatically be granted it. This removes the need for separate birthright policies.
Luna
Luna reviews your access weekly and proposes policies worth writing down; they appear on the Suggested policies card at the top of the Policies tab. The Ask Luna about your policies card next to it is the same conversation as the floating chat bubble, not a second one. Luna can also draft a whole access model, draw your estate, and preview a policy before anything is created.
Luna is held to the same permission as the page, so what Luna will tell someone about policies is exactly what that person could see themselves.
Good to know
Policies also appear read-only in two other places: a resource's Policy tab ("Targeting this resource", plus any org-wide denials), and a member's "Why they have this" panel.
Employees only ever meet the outcome of a policy, never the policy itself.
Deleting a policy does not take anyone's access away by default. The access stays and simply stops being explained, which moves it into Unexplained on the coverage ledger. Removal is a separate, opt-in choice in the delete dialog, and it goes through your normal approvers.
Coverage percentages are counted over grants, not over policies, so "we have 30 policies" and "30% of access is explained" are different measurements. Coverage is recalculated every 5 minutes.