What an access policy is
An access policy in ploy is a way to configure and enforce who should have access to what, for how long and under what conditions. Ploy has a single policy engine to power all access across your company, giving you a clear and single place to manage access.
With policies, you declare what you want the state of your access to be and the Ploy policy engine makes it so, 24/7 365 days a year.
The sentence: who, effect, what
Every policy is built from three parts, and Ploy writes the sentence for you as you choose them.
Who is a filter over your people: attributes like department, job title, team, employment type and location, saved profiles, or named individuals. Leave it empty and it reads Everyone.
The effect is what should happen: Gets, Never gets, Can request, Can't request, Must satisfy, or Remove when unused.
What is the target: a whole app, or a single permission inside an app.
Real sentences from a live account read like this:
Everyone can request Slack for up to 3 months at a time, not extendable, no reason required
People where (department is not IT or department is not set) can't request production access & 1 more
Access to Google unused for 5 days is removed
You can give a policy a name. If you leave the name blank, the sentence is the name everywhere the policy appears.
It keeps applying, it is not a one-off
A policy is evaluated continuously, not run once. When someone joins the population, changes department or leaves it, the policy reaches the new answer on its own. Saving a policy triggers an immediate pass for that policy, and a safety sweep runs across your organisation every 15 minutes to catch anything the immediate pass missed.
Who can see them
Policies are an admin surface. You need the access policy permission to open the Policies tab, and the same permission applies when you ask Luna about policies, so an ordinary employee cannot get a policy read out to them in chat either.
Employees never see a policy's name, sentence, effect or author. They see only the outcome: what is in their request catalog, what terms a request carries, and a refusal when one applies.
Good to know
A policy that grants access must name a specific app or permission. Everything, the org-wide target, is only available on the deny and request effects.
If a policy's target is deleted, the sentence says "a resource that no longer exists" rather than quietly reading as "everything".
On the Policies tab a policy is Active or Disabled. Proposed, Dismissed and Deleted only appear on the embedded policy panels elsewhere in Ploy.
Cards carry chips for the effect, the enforcement setting, the manual override setting, "Overlaps N policies", and an amber "{N} awaiting review" chip when someone has contradicted the policy by hand.
Nothing about the order of policies in the list decides anything. Precedence comes from the effects, never from which policy you wrote first.