River
Y CombinatorBacked by Y Combinator

Business & Revenue OpsFree

CRM Permissions and Access Review

Send your CRM user export and your current employee list, and get every departed account with live access flagged and ranked by risk.

Context to provide

A user list marked Active tells you who has a login, not who still works there. Take an illustrative example: Callahan Devices, a fictional 140-person equipment distributor, checks its 165 Active CRM accounts against the employee list from its HR system. It matches every account to a current employee by name or email rather than trusting the CRM's own status field. 142 match. The other 23, 13.9 percent of every account marked Active, belong to people who no longer work there.

Six of those 23 carry Sales Manager or System Administrator permissions, meaning they could export the full pipeline or change anyone's records. Average time since those six people left: 142.8 days. The longest belongs to an administrator who left 340 days, nearly a year, before anyone checked. Keeping all 23 unused seats costs $1,495 a month, $17,940 a year, in licenses nobody was using and nobody had cause to notice.

This tool runs that same match on your export, every account checked by name or ID rather than by last login, which a departed account can still pass if someone kept using the credentials after the person left. It also runs a second check a manual review usually skips: permission creep among users who are still active. In the example, 17 of 96 active Sales Reps carry permissions above their role's normal set, picked up project by project and never removed.

The manual review checks a box; the identity match finds the account

The usual approach is a spreadsheet: a review template with one row per user, a column for role and access level, and a decision field, usually approve, modify or revoke. The reviewer leans on last login and employment status to decide, and both come from the system under review. A departed account nobody disabled reports the same status it always did, because nothing outside the CRM ever checked it against anything. The review gets signed, and the account stays live.

Permission creep is the same gap seen from the other side. Access granted for one project in 2023 is often still in place years later, because nobody owns the step of taking it back. The usual fix is a reviewer asking whether each grant still matches the job, a judgement call repeated row by row rather than a count. Almost nobody compares each person's permissions against what everyone else in the same role holds, which is the one comparison that makes outliers obvious.

Both gaps close the same way: check against a source the CRM itself does not control. An HR or single sign-on export says who is actually employed today, independent of any status field inside the CRM. The most common permission set for a role says what a Sales Rep normally holds, independent of what any one rep has gathered. NIST's federal account management control says account managers must be notified when a user is terminated or transferred, the notice a CRM status field cannot generate itself.

How it works

  1. Send both exports

    The CRM's user, role and permission export, plus your HR or single sign-on list of current employees.

  2. Every account gets matched

    Each CRM account checked against the current employee list by name, email or ID, not by recent activity.

  3. Unmatched accounts get ranked

    Departed accounts with live access ranked by permission level, with days since termination and license cost.

  4. 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 current employee list by name, email or ID, not by last login
  • Departed accounts with live access named one by one, with permission level and days since they left
  • Departed accounts ranked by risk, since export or edit-all access matters more than read-only
  • Active users checked for permission creep against what most people in the same role hold
  • The monthly and annual license cost of every departed account still enabled, when you give a seat price
  • A ranked revocation list ready to act on, plus a policy for catching the next departure sooner

Common questions

What counts as a current employee list?

Whatever your organization uses to track who is employed today: an HR system report, your single sign-on provider's active-user list, or a roster IT maintains. It needs to come from outside the CRM, since the whole point is checking the CRM's status field against a source it does not control. Work email or employee ID makes the match exact.

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 done by hand still depends on a reviewer remembering, or being told, who left. This does the one check that review depends on, a real match against the employee list, and it does not get worse when the reviewer is busy or new. Run it before each quarterly review, and the review starts from named accounts instead of a blank sheet.

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

Describe what you need, add any files you have, and your workspace opens with the work already underway.