Salesforce · access and permissions
Nine access risks,
and an agent inherits all of them.
Access accumulates. Every grant made in a hurry is still there, and until this year that was a tolerable kind of untidy. It stopped being tolerable when agents started running as a user and seeing exactly what that user sees.
Reviewed 26 August 2026, after the July MFA rollout.
What changed this summer
MFA reached everybody, and it solved a different problem.
Multi factor authentication for all employee users started in sandboxes on 22 June 2026 and in production on 20 July 2026, staggered over roughly thirty days. Two details matter more than the date. Administrators can no longer switch the org wide setting off. And the permission that used to waive multi factor authentication for exempt users no longer exempts anybody, so accounts that relied on it now prompt for enrolment at login.
It is worth being precise about what that fixed. Multi factor authentication governs who gets through the door. It says nothing about what they can reach once inside. An over permissioned account with multi factor authentication enabled is still an over permissioned account, and this year that account may also be an agent.
The nine
Nine risks, and most orgs have at least three of them running.
Each one exposes data or breaks an integration on its own. They are listed in the order worth checking, which is not the order of severity: the cheap checks come first because finding three of these in an afternoon changes the conversation about the rest.
Users who kept access they were granted once
Somebody needed access quickly to fix something urgent, it was granted on the profile, and nobody walked it back. Repeat that for a few years and a coordinator can export every opportunity in the org.
Integration users scoped to everything
A credential running around the clock has the widest reach in the org. Salesforce guidance is to create a separate integration user per integration, scoped to what it touches, so a misfire is contained to one system instead of the whole database. Shared integration users are the opposite of that.
The connector user nobody has reviewed
The Pardot or Account Engagement connector user is usually configured once and never looked at again. It typically has more than it needs, and it is the account least likely to appear in a security review because nobody thinks of it as a user.
Field level security left open by default
The most granular layer and the one most often untouched. A field added by an admin in a hurry is visible to everybody unless somebody decided otherwise, and nobody decides retroactively.
Access granted on profiles instead of permission sets
Access on a profile cannot be removed from one person without affecting everybody who shares that profile. So it is never removed. The permission set led model exists precisely so that a grant can be taken back.
Roles used to fix what profiles control
Profiles decide what you can do. Roles decide which records you can see. Permission sets add on top. Fixing a record visibility complaint with a profile change is the most common wasted afternoon in Salesforce administration.
Sharing rules that grant more than anybody remembers
Criteria based rules accumulate. Each was reasonable when written, and the combination is not described anywhere. Counting the resulting share rows is the only honest way to know what access exists.
Departed users still active
Licences cost money and inactive accounts are a way in. The check takes minutes and is skipped because nobody owns it.
No record of who granted what, or why
The risk that produces all the others. Without a written model, every grant is permanent, because removing it means guessing what it was for.
The distinction that decides everything
Profiles, permission sets and roles are three different questions.
Profiles define what you can do. Roles define which records you can see. Permission sets add flexible access on top. Confusing them is the reason audits produce findings that change nothing, because the fix is applied to the wrong mechanism and the symptom survives it.
The practical rule: a complaint that sounds like I cannot see that record is a role or sharing question. A complaint that sounds like I cannot do that is a profile or permission set question. Getting that wrong costs an afternoon every time, and it is the single most common wasted afternoon in Salesforce administration.
Asked often enough to answer here
Questions
What does a Salesforce permissions audit actually check?
Who can see and do what, across four mechanisms: profiles, permission sets, roles and field level security. It measures effective access against least privilege and produces a ranked list of findings, not an inventory of features. The useful output is which people and which integrations have more than the job needs, and what removing it would break.
What is the difference between profiles, permission sets and roles?
Profiles define what you can do. Roles define which records you can see. Permission sets add flexible access on top of a profile. Mixing them up is the most common reason an audit produces findings that change nothing: a permission set change does not fix a role hierarchy problem, and a role change does not grant an object permission.
What changed when MFA reached all employee users?
Multi factor authentication for all employee users started in sandboxes on 22 June 2026 and in production on 20 July 2026, staggered over roughly thirty days. Two things are worth knowing. Administrators can no longer switch the org wide setting off. And the permission that used to waive multi factor authentication for exempt users no longer exempts anybody, so accounts that relied on it now prompt for enrolment at login.
Does MFA replace a permissions review?
No, and treating it as one is the mistake worth avoiding this year. Multi factor authentication governs who gets through the door. It says nothing about what they can reach once inside. An over permissioned account with MFA enabled is still an over permissioned account.
Why does Agentforce make this urgent?
An agent does not have its own access. It runs as a user and can see and do exactly what that user can. Every field left visible to that user is visible to the agent, and anything the agent can read it can surface. That turns a tolerable permissions model into a live exposure, which is why access is reviewed before an agent is deployed rather than after.
How do you run one without clicking through every user?
You export the grants rather than reading screens. The User Access and Permissions Assistant on AppExchange reports who has what and, more usefully, how they got it. Then the five moves are: export every grant, find the over access, scope the integrations, close the sensitive fields, and write down a permission set led model so the next grant can be removed.
The paid check is €500 and runs against your own exports, delivered within three working days and credited against the work if you go ahead. Remediation is quoted in hours at fifty euro from what the check finds, and every price is published here. The nine checks above can also be run by your own team, which is why they are written out rather than summarised.
Serhii Skrypnyk · Senior Salesforce Administrator and developer · 7 Salesforce certifications · on the platform since 2018. Reviewed 26 August 2026.