Business & Revenue OpsFree
CRM Permissions and Access Review
Send your CRM user export and your SSO or HRIS active-employee list, and get every departed account with live access flagged and ranked by risk.
A user list marked Active tells you who has a login, not who still works there. Callahan Devices, a 140-person industrial equipment distributor, checked its 165 Active CRM accounts against the active-employee list from its own HRIS export, matching every account to a current employee by identity rather than trusting the CRM's own status field. 142 matched. The other 23, 13.9 percent of every account marked Active, belonged to people who no longer worked there.
Six of those 23 carried Sales Manager or System Administrator permissions, meaning they could export the full pipeline or modify anyone's records. Average time since termination on those six: 142.8 days. The longest-lived one belonged to an administrator who left 340 days, nearly a year, before anyone checked. Carrying all 23 zombie seats cost $1,495 a month, $17,940 a year, in licenses nobody was using and nobody had cause to notice.
This tool runs that same identity match on your export, every account checked by name or ID rather than by last-login recency, which a departed account can still pass if someone else kept using the credentials after the person left. It also runs a second check the manual review skips entirely: permission creep among users who are still active. At Callahan, 17 of 96 active Sales Reps carried a permission set above their role's own default template, accumulated project by project and never stepped back down.
The manual review checks a box; the identity match finds the account
Page one for this query is a spreadsheet: a review template with one row per user, a column for role and access level, and a constrained decision field, usually Approve, Modify or Revoke. Zluri's own walkthrough calls last login and employment status inputs to that decision, both self-reported by the system under review. A departed account nobody disabled reports the same employment status it always did, because nothing outside the CRM checked it against anything.
AuditForce's Salesforce checklist names the same gap from the other side without ever closing it, filing it under permission creep: 'access granted just for this project in 2023 is often still in place' by 2026. The fix it offers is a reviewer asking whether each individual grant still matches the job, a judgment call repeated per row rather than a count. Nothing on page one compares a permission set against what the role's own default template grants everyone else holding it.
Both gaps close the same way: check against a source the CRM itself does not control. An HRIS or SSO export says who is actually employed today, independent of any status field inside the CRM. A role's default permission template says what a Sales Rep is normally granted, independent of what any individual rep has accumulated. NIST's federal account management control states account managers must be notified when a user is terminated or transferred, which is exactly the notification a CRM's own status field cannot generate on its own.
How it works
Send both exports
The CRM's user, role and permission export, plus your SSO or HRIS active-employee list.
Every account gets matched
Each CRM account checked against the active-employee list by identity, not by activity or a status field.
Unmatched accounts get ranked
Departed accounts with live access ranked by permission level, with days since termination and license cost.
Get the revocation list
Every account to disable, in order, plus a policy for catching the next departure sooner.
What you get
- Every CRM account matched to your active-employee list by identity, not by last login or a status field
- Departed accounts with live access named individually, with the permission level and days since termination
- Zombie accounts ranked by risk, since export or edit-all access matters more than read-only
- Active users checked for permission creep against their role's own default template, not a reviewer's guess
- The monthly and annual license cost of every departed account still enabled, a number attached to every revocation
- A revocation list ready to act on, plus a policy for catching the next departure before it ages
Common questions
What counts as an identity export?
Whatever your organization uses to track who is currently employed: an HRIS report, an SSO or identity provider's active-user list, or an IT-maintained roster. It needs to be independent of the CRM itself, since the whole point is checking the CRM's status field against a source it does not control.
Isn't this just an inactive-user report?
No. An inactive-user report flags accounts by login recency, which a departed employee's account can pass if a manager or colleague kept using the login, or fail on an active employee who was simply on leave. Matching against an independent employee list catches both cases correctly, which login recency alone cannot.
How is this different from the general CRM audit?
The audit prices a full cleanup across duplicates, fields and automations, with access as one line among several. This tool does the identity match and the permission-creep check in depth, on their own, for whoever needs specifically the access answer rather than a whole scoped project.
What if we don't have a formal permission set structure?
The tool works from whatever roles or profiles exist, even an informal one, and states plainly where the export cannot support a clean role-default comparison. The identity match against departed staff still runs regardless, the same way a field dictionary documents whatever fields actually exist rather than waiting for a clean schema first.
We already have a quarterly access review. Why add this?
A quarterly review run as a manual walk-through still depends on a reviewer remembering, or being told, who left. This automates the one check that review depends on: a real match against the employee list, which does not degrade when the reviewer is busy or new to the account.
Does this cover systems beyond the CRM?
No, this tool is scoped to the CRM's own user and permission export. For an access review across every system an SSO tracks, not just the CRM, the general user access review template covers the wider identity surface this tool does not.
What happens to the accounts after they're flagged?
The output is a revocation list ranked by risk, plus a going-forward policy: the trigger that should disable a CRM account automatically when someone leaves. Whether disabling happens through the CRM's own admin tools or a connected identity system depends on what you already have set up.
CRM Permissions and Access Review
Fill in the form and your workspace opens with the work already underway.