Change who can see what, on the record
Access changes are the ones most likely to go wrong quietly. Each one is a metadata change to profiles, permission sets, and permission set groups — so each one can be described, reviewed as an exact diff, and put back.
Permission grants only ever accrete
Two routine requests, both easy to get subtly wrong.
A new hire needs access "like Priya’s." The fast, correct-looking move is to clone Priya’s profile and adjust. The clone carries everything Priya has, including grants she inherited from a clone someone made two years ago and a permission set assigned for a project that ended. You have just copied exposure you never inspected.
Someone leaves. Deactivating the user stops them logging in. The permission sets that were built around them, the sharing rules written for their role, the field-level access granted for their project — all still defined, now attached to nothing, waiting to be inherited by the next clone.
Neither is carelessness. Nothing in Salesforce expires a grant or reminds you it exists, so the org gets slowly more permissive until an audit or an incident asks the question directly.
Access is metadata, so a change to it can be read and undone
A profile, a permission set, the field-level security on a sensitive object: all configuration stored as text. A change to access can be described, reviewed as an exact diff, and reverted, exactly like a change to a field or a layout. Access changes feel riskier because the interface shows them per user and per profile, never in aggregate, so you cannot easily see the whole of what you just granted.
Once the change travels through a repository, it stops being a click you have to remember and becomes a record you can point to. Which grant moved, when, and why is written down at the time — the exact question a security review asks later.
Scope note: FlowSprite changes permission metadata. Activating, deactivating, and licensing individual users stays in Salesforce Setup — you can scope the connected app so FlowSprite can never touch user management at all. See the permission boundaries.
What a clean access change looks like
Described in plain terms
"Give the SDR permission set read and edit on Lead and Opportunity, no export, no access to the compensation fields on Employee." The request is the terms you would use to a colleague, not a profile screen.
The exact grant as a diff
It comes back as the specific permissions added or removed, visible line by line, so you approve what actually changed rather than what you intended to change.
A sandbox to see it in
The change lands in a real org first, where you can confirm the permission set lets its holders do the job and not see what they should not.
A record and a way back
The grant is committed to your repository with who approved it and why, and it can be rolled back by redeploying the prior tagged state. Removing access travels the same route as adding it, and the removal is on file too.
The point is not that the change is faster to make. It is that "who can do what, and how did it get that way" has an answer you can read on the day you are asked, instead of a week of clicking.
Who this is for
Anyone who would currently answer "who can see this?" by opening profiles one at a time.
Alone, this is the difference between managing access and hoping it is still correct: you make the change, and the record of it is kept without you maintaining a spreadsheet. On a small team, it is a shared and current statement of which grants exist, so two admins are not each carrying a different idea of the org’s real permissions. With auditors or a security reviewer involved, it is a history that shows both the current state and how it got there, which is usually the harder half of what they ask for.
Why access is the change class to get right first
Access is the change with the widest consequences and the weakest feedback. A broken flow announces itself within a day; an over-permissioned field does not announce itself at all, until it becomes expensive. Making permission changes travel the same recorded, reversible route as everything else is what stops the slow, silent widening that every long-lived org accumulates.
Send your next permission change through a sandbox
Describe the grant in plain English and watch it land in a sandbox before it reaches anyone real.
Start free in 2 minutes