Before you start
Policies are only as good as the data they match on and the plumbing they act through. Five minutes of checking here saves a policy that matches nobody, or one that matches everyone and grants nothing.
1. HR attributes filled in
The Who builder matches on the attributes Ploy already holds about your people: department, team, job title, employment type, location, employment start and end dates, and any custom fields your organisation has added.
If those are mostly blank, a policy can only say Everyone or name individuals one by one, which is exactly the shape you are trying to get away from. Check a handful of people in Employees first. If departments are empty for most of the company, fix the feed before writing policies, not after.
2. Profiles for the cohorts you already think in
A profile is a saved, named cohort, and it is the thing to reach for when you find yourself rebuilding the same filter twice. The builder's own note says it best: a profile keeps being true as people move teams. If you don't know what your profiles should be, ask Luna!
3. Provisioning set up on the apps you will grant
A Gets policy grants access through the app's own provisioning strategy. If an app has none, the builder shows an amber strip while you are authoring: "{N} resource(s) can't provision access yet", with the body line "Until provisioning is set up for {names}, this policy will not grant access to anyone." There is a Set up provisioning button on the strip that opens the setup without losing your draft.
Request policies and deny policies do not need this. Only the effects that actually hand out access do.
4. The permission to author policies
The Policies tab is an admin surface. If you cannot see it, you do not have the access policy permission, and asking Luna will not route around it: Luna answers with the same refusal, pointing at "Access, Managed access, Policy" and telling you an organisation admin can do it.
Decide up front who in your organisation holds that permission. Everyone else sees only the outcomes of your policies.
5. Know the confirmation threshold
When a policy would act automatically on a lot of people, Ploy stops and makes you confirm the number. The threshold is 50 people by default, and the gate only applies when enforcement is stronger than Suggest only.
You will meet it in the builder's footer rather than in a separate dialog. The footer turns amber and reads "Activating applies this to N people today. That's above the confirmation threshold (50)", with Back and Save for N people.
The threshold is set by Ploy rather than in the product, so if 50 is the wrong number for your organisation, ask us to change it.
Good to know
The People / NHIs toggle in the builder only appears if non-human identity populations are switched on for you. Without it, policies are about people only.
An access's own properties, such as the permission level it grants or when it was last used, cannot be used to choose people. Those belong in a Must satisfy condition instead.
On-call status can only be used on the request effects, not on a grant or a deny.
The default for Remove when unused is
60days without use, which you can change per policy.