Article 5: Assigning Reviewers
How reviewer assignment works in Ploy
When a review cycle is generated, Ploy automatically assigns each account to a reviewer based on the assignment configuration you've defined on the campaign. Reviewers receive a notification and can access their assigned accounts directly in the employee portal.
You don't manually assign reviews account-by-account — you define the rules for how assignment should work, and Ploy handles the rest at cycle generation time.
Assignment configurations
Assignment is driven by assignment configurations — saved, reusable rules that you create and attach to a campaign. You can create a new configuration when building a campaign, or pick an existing one from your library.
An assignment configuration defines:
The primary assignment strategy (how reviewers are selected)
Any per-resource overrides (exceptions to the primary rule)
Fallback reviewers (who covers if the primary reviewer is unavailable)
Assignment strategies
Ploy supports several strategies for determining who reviews what:
Direct assignment
You specify exactly which Ploy user(s) should review accounts matching specific criteria. Best for cases where a specific person is the natural owner — for example, always routing Salesforce reviews to the CRM administrator, or always routing finance tool reviews to the Finance Director.
Round-robin
Accounts are distributed evenly across a pool of reviewers. Useful when you have a team of people who can all review access of a given type (e.g. a security team reviewing all admin access), and you want to balance the workload.
Resource-based routing
You can configure resource-based routing so that accounts are routed to a specific reviewer based on the resource e.g. Owners. This is commonly used to have resource owners or team managers review access to their own tools.
Per-resource overrides
Overrides let you set reviewer rules that apply only to specific resources (apps), overriding the primary strategy for those resources.
Example: Your primary strategy is round-robin across your security team, but you want Okta admin access always reviewed by your IT Director. You add an override: Resource = Okta → assign to [IT Director].
Overrides can be configured to:
Assign — replace the primary assignment entirely with a specific reviewer or set of reviewers
Add — add additional reviewers on top of the primary assignment
Exclude — remove specific people from reviewing a particular resource (e.g. avoid self-review conflicts)
Account sets
When Ploy generates a cycle, accounts are grouped into account sets — one set per unique reviewer assignment. This means:
All accounts assigned to the same reviewer are in one set
A reviewer submits their set as a unit (not account-by-account)
Each set has its own approval status, separate from other sets within the same review
This matters when a single review (e.g. "GitHub") has accounts assigned to multiple reviewers — each reviewer sees only their set, and admins can track and approve sets independently.
Fallback reviewers
If a primary reviewer is not available — for example, they've left the company or the assignment rule returns no match — Ploy falls back to the reviewer(s) defined in the fallback configuration.
Always configure a fallback. Without one, an account set with no valid reviewer will stall the review cycle.
Changing reviewers mid-cycle
If a reviewer is assigned to a cycle but is unable to complete their review (e.g. they go on leave, or they're the wrong person), admins can reassign the account set from the admin dashboard. Reassigning a set:
Moves it to the new reviewer
Notifies the new reviewer that they have accounts to review
Triggers Ploy to generate a fresh set of Luna AI recommendations for the new reviewer
Self-review prevention
Ploy does not automatically prevent self-review (an employee reviewing their own access), so it's important to structure your assignment rules to avoid this — particularly for admin access reviews. Use the exclude override where needed.
Practical tips
Resource owners as reviewers work well for most SaaS tools — the person who manages the tool day-to-day usually knows who should and shouldn't have access.
Managers as reviewers work well for access that's tied to job function — they can answer whether a direct report still needs a particular tool.
IT/security team as reviewers works best for elevated-privilege access (admin roles, finance tools, infrastructure) where only a technical person can assess appropriateness.
Always set a fallback — a missed review due to an absent primary reviewer is a compliance gap.
Keep reviewer pools small — round-robin across 2-3 people is far more manageable than distributing across a large group where accountability diffuses.