Simulate a person
Simulate a person answers one question: if Ploy applied every active policy to this individual right now, what would they get, what could they ask for, and what is closed to them? Nothing you do here changes anyone's access.
Run a simulation
Go to Managed Access, then the Policies tab.
Click Simulate a person in the toolbar. The drawer opens with the subtitle "See exactly what today's policies decide for someone, before anyone's affected."
If your organisation writes policies about non-human identities, a People / NHIs toggle appears at the top. Pick which population you are simulating. If you only write policies about people, no toggle is shown.
Search the picker for the person. The placeholder is "Search people by name or email", or "Search NHIs by name or id" for a machine identity.
Select them. Ploy shows their identity header and the attribute sections policies match on, such as job title and department, followed by the results.
Click Done when you have finished. The footer reminds you: "Read-only. Nothing here changes access."
Reading the results
If nothing applies, Ploy says so directly: "No policy touches {first name} yet, so they'd get nothing from the current rules."
Otherwise it opens with how many policies apply, then lists every decision they would trigger in four fixed buckets:
Bucket | What it means for that person |
|---|---|
Gets | Ploy grants this access and keeps it true from then on. |
Can request | They can ask for it, through the winning policy's ladder and terms. |
Never gets | This access is refused to them. |
Can't request | Hidden from their catalog, and asking is refused. |
Each row names the app or entitlement and carries a "via {policy}" trailer, so you can always see which policy produced that line. Where another policy overrules it, the row is struck through and labelled "Blocked by {policy}". That is the precedence laws showing their work: a refusal beats a grant, and refusing the ask beats permission to ask.
Good to know
The simulation reflects active policies only. A Disabled policy or a suggestion you have not accepted contributes nothing, which makes this a good way to check a policy is really off.
It answers "what should be true", not "what is provisioned today". A row in the Gets bucket means the policy calls for that access, not that the person already holds it. To see what has actually landed, open the policy and read its Details tab, or use the coverage ledger.
Only the four decision buckets are shown. A Must satisfy or Remove when unused policy places no row here, because neither hands out or refuses access.
Use it before a difficult conversation, not after. It is the fastest way to answer "why can this person not request Salesforce", because the blocking policy is named on the row.
It reads whoever you pick, not just yourself. Simulating someone is a read of their attributes and the policies that match them, so it needs the same permission as viewing policies. If you cannot open the Policies tab, you cannot simulate.
Ploy's assistant can drive this drawer. Luna can open it, pick a person and run the simulation using exactly the controls you click, so a chat answer about a person and the drawer on screen cannot disagree.
Bookmark it. The drawer keeps its own address, so a link to the Policies tab with the simulation open reopens it after a reload or when shared with a colleague.