Salesforce Security Review: Profiles, Permission Sets and Sharing Done Right

One disambiguation before anything else, because two different things carry this name.

If you arrived looking for the AppExchange Security Review, the assessment an ISV passes before listing a managed package, this is not that page. This covers reviewing permissions inside your own org: who can see which records, which fields, and through what mechanism. Both get called a Salesforce security review, and the second one is the review nobody schedules until something goes wrong.

It also became more interesting in June 2026, because Salesforce changed its position on the thing most permission roadmaps were built around.

Salesforce cancelled the retirement of permissions in profiles

Anyone planning permission work from guidance written before mid-2026 is working to a deadline Salesforce has since withdrawn.

Salesforce’s help article Permissions in Profiles Retirement Cancelled, published 6 June 2026, is direct about it. Profile permissions had been scheduled for retirement from Spring ’26. Salesforce now states that the enforcement is cancelled, and gives two reasons for the reversal: what customers told it, and feature gaps that remain unclosed.

Note the word. Cancelled, not postponed. This followed an earlier retreat from enforcing the Spring ’26 end-of-life date, so the pattern is two steps back from a stated deadline.

That same article keeps the recommendation while removing the compulsion. Profiles will continue to support permissions for now, and Salesforce recommends transitioning to a permission set-led security model for improved flexibility and scalability. It also names where the investment is going: improved user management in Setup, permission sets and permission set groups, and summary views with admin usability improvements.

What changes for you is the argument, not the direction. Migration was a compliance project with a date attached. Now it is an architecture decision you justify on merit, which is harder to fund and easier to postpone indefinitely.

GetGenerative.ai enumerates the permission model before anyone argues about it

Permission reviews stall at the first step, which is finding out what you currently have.

Nobody can review what they cannot enumerate, and a mature org holds permissions across profiles, permission sets, permission set groups, muting sets, sharing rules, role hierarchy, territory assignments, manual shares and whatever Apex sharing somebody wrote in 2019. Assembling that picture by clicking through Setup is why these reviews get scheduled and then quietly dropped.

GetGenerative.ai’s Metadata Agent reads the org’s permission metadata directly, which turns the inventory step from weeks of manual collation into something you can put in front of stakeholders on day one. The Design Agent then holds the target model, so the gap between current and intended state is a document rather than an argument. Where that fits a wider review of org condition is covered in the assessment that reads an org through its metadata.

Judgment stays with people. Deciding that finance should not see deal margins is a business decision, and no agent should make it. Finding every place that permission is currently granted is clerical work that should never have consumed a consultant’s week. If the ongoing version of that is your problem, what BAU org support covers sets out the running model.

Salesforce now assigns profiles six responsibilities and permission sets ten

Cancellation came alongside the clearest division of labor Salesforce has published, which makes it the right basis for a review standard.

Two instructions accompany that table and both are quotable in a review document. Assign users the Minimum Access – Salesforce profile, or a clone of it, as the stated best practice. And avoid adding permissions directly to profiles where possible.

Read the right-hand column as your review scope. Every item there is something that should be grantable and revocable without touching a profile, and in most orgs several of them are not.

Permission set groups align to job function, not to person

Groups are the mechanism that makes a permission set model manageable rather than merely correct.

Salesforce’s guidance is to combine multiple permission sets into permission set groups, align those groups with user roles or job functions, and use them to simplify assignment and management. Design discipline here is simple: a group represents a job, a permission set represents a capability. One capability can appear in several jobs, which is the whole point and the reason this scales where profile cloning does not.

A review catches the failure mode quickly. Count your permission sets and your users. If the ratio is close to one to one, you have rebuilt profiles with a different object name and inherited none of the benefit.

User Access Policies automate assignment, which is where migrations actually fail

Designing the target model is the part teams enjoy. Moving thousands of users onto it is the part that stalls.

Salesforce’s migration recommendation runs in five steps: plan and document your current permissions model, design permission sets and groups based on user roles, use User Access Policies to automate assignments, test thoroughly in a sandbox environment, then roll out to production.

Step three is the one that makes the rest survivable. Manual reassignment across a large user base is slow, error-prone and impossible to repeat, so the policy mechanism is what converts a one-off project into a rule that keeps applying to new joiners. Step four deserves its own emphasis too, because permission changes behave differently against real data volumes and real role hierarchies, and the environment where that gets proven is a planning decision rather than an afterthought.

Field-level security is the fastest-rising question in this area

Worth knowing what people are actually asking, because it tells you where a review gets challenged.

Google Trends over the twelve months to late October 2026 puts average interest in permission sets slightly ahead of salesforce security review, with salesforce sharing rules far behind both. More useful than the ranking is the movement: the fastest-rising related query attached to salesforce security review is field level security in salesforce, up around 120 percent.

That matches where reviews find problems. Object-level access is visible and gets audited. Field-level security hides inside page layouts and permission sets, and a field that should be invisible to a role is usually invisible on the layout rather than restricted by permission, which means it remains available through reports, the API and now through agents.

Agents lose user identity by default, which breaks least privilege silently

Here is the part of a permissions review that did not exist two years ago, and it is the one with the sharpest consequences.

Salesforce’s architecture guidance on end-user identity propagation in agents states the problem plainly. User identity is lost by default. When an agent calls an MCP server or downstream API using client credentials, the request carries the agent’s service identity rather than the end user’s, and the downstream service has no way to know which user initiated the action, which makes per-user authorization and audit trails impossible.

Salesforce also names the trap on the other side. Passing the original user token through every hop violates the principle of least privilege, while using a service account loses the user’s identity. Neither default is acceptable, and the guidance is equally clear that propagating user tokens where they are not needed expands the attack surface.

Three patterns resolve it, and a review should establish which one applies to each agent action.

On-Behalf-Of, where user identity is preserved through a token exchange scoped to each downstream service, with no user interaction. Correct for user-specific data inside one trust domain, such as an agent retrieving a customer’s own records.

Server-to-Server, where user identity is deliberately not propagated and the calling service’s own credentials are used. Correct for public or system-level data, where propagating a user token would add exposure for no gain.

In-Task Authorization Code, where the user authenticates inline with an external provider during the conversation. Correct for cross-domain and higher-risk operations, where a token from your identity provider means nothing to the target system.

One architectural principle underneath is worth carrying into your standards: identity propagation is enforced at the gateway layer rather than inside agents or services, so agents hold no authentication logic. Salesforce’s own summary of the stakes is the line to quote in a governance paper. Without trusted identity propagation, governance is incomplete, because you can catalog and orchestrate agents and still not ensure they act within the boundaries of the user’s authorization.

An agent inherits a permission model it did not design

Follow that through to the practical review question, because it reframes old findings as new risks.

An agent answers in natural language from whatever its user context can retrieve. Over-granted field access that survived five years because nobody built a report on it becomes a sentence in a chat window. A sharing rule written broadly for convenience becomes an answer about an account the asker was never meant to see. Your permission model did not change. The number of ways to interrogate it did, which is the whole shift.

Two review items follow. Every agent needs a named user context with its permissions documented, rather than inheriting an administrator’s. And the checks you run before switching an agent on should include a read of what that context can reach, which is part of the readiness checks that precede turning agents on.

Sharing grants record access, and only one mechanism takes it back

Permissions answer what a user can do with an object. Sharing answers which records, and the two get conflated in most review conversations.

Sharing starts restrictive and opens up. Organization-wide defaults set the floor, then role hierarchy, sharing rules, teams, manual shares and Apex sharing grant access above it. Everything in that stack grants, which is why an org whose defaults were set to Public Read Write in year one cannot be tightened later without discovering which business processes quietly depended on the gap.

One mechanism does subtract, and a review should know its limits before relying on it. Restriction rules filter the records a user already has access to, so they reach only the ones matching criteria you specify, applying on top of organization-wide defaults and sharing rules. Four constraints matter. They cover a limited object set, named by Salesforce as custom objects, external objects, contracts, events, tasks, time sheets and time sheet entries, so Account, Opportunity, Contact and Case are not among them. They support only the EQUALS operator, with no AND or OR. Enterprise and Developer editions allow up to two active rules per object, Performance and Unlimited up to five. And they are bypassed entirely by View All Records or View All Data for reading, and by Modify All Records or Modify All Data for reading, editing and deleting.

Scoping rules are the mechanism most often mistaken for this one. Salesforce is explicit that a scoping rule does not restrict access to other records a user sometimes needs. It filters what appears by default in list views, reports and SOQL, and the user can still reach anything their sharing allows. Treating a scoping rule as a control is a review finding, not a mitigation.

A review should state the organization-wide default per object and the justification for every mechanism layered on top. Mechanisms without a stated reason are the ones to question, because each one is a standing grant that outlives whoever requested it. Who approves changes to any of this belongs in the forum where access decisions get signed off, and the data-side policies that sit beside it are covered in the rules governing what agents may ground on.

What a review should produce, in order

Findings, not observations. Each item needs a current state, an intended state and an owner.

Start with an enumeration: every profile with permissions attached, every permission set and group, the organization-wide default per object, and every sharing mechanism in force. Then compare against Salesforce’s own split, treating anything in the permission-set column that currently lives on a profile as a finding. Record each one the way a design decision and its rejected alternative get written down, since a permission granted without a recorded reason is the thing you will be unable to revoke later.

Next, test field-level security against the API rather than the page layout, since that is where the gap hides, and check whether any control you are relying on is a scoping rule rather than a restriction rule. Then document each agent’s user context and what it can retrieve, and assign each agent action one of the three identity patterns.

Schedule the re-run before you close the first one, because permissions drift with every release and every joiner, and the cutover checks that precede go-live are the wrong place to discover a sharing default nobody reviewed.

Finish with the two questions that decide whether the review was worth running. Can a permission now be granted and revoked without editing a profile? And can you name, for any sensitive field, every path by which a user could reach it, reports and agents included?

Questions that come up during a permissions review

Did Salesforce retire permissions in profiles?

No. Salesforce announced the retirement starting in Spring ’26 and then cancelled the enforcement, confirmed in a help article published 6 June 2026, citing customer feedback and remaining feature gaps. Profiles continue to support permissions, while Salesforce still recommends moving to a permission set-led model for flexibility and scalability.

What belongs in a profile versus a permission set?

Salesforce assigns profiles the default settings: default assigned apps, default record types and page layouts, login hours, login IP ranges, password policies and session settings. Permission sets and groups take object permissions, field-level security, user permissions, custom permissions, tab settings, non-default record types, Visualforce page access, Apex class access, connected app access and non-default assigned apps. The stated best practice is to assign the Minimum Access – Salesforce profile or a clone, and to avoid adding permissions directly to profiles.

How do you migrate from profiles to permission sets?

Salesforce’s recommended sequence is to plan and document the current permissions model, design permission sets and groups around user roles, use User Access Policies to automate the assignments, test thoroughly in a sandbox, then roll out to production. The automation step is what makes the migration repeatable for new joiners rather than a one-time exercise.

Is the Salesforce Security Review the same as reviewing permissions?

No, and the name collides. The AppExchange Security Review is the assessment an ISV passes before listing a managed package, run by Salesforce’s product security team. Reviewing profiles, permission sets and sharing is internal org work on who can reach which records and fields. Search results for the phrase return mostly the AppExchange process.

What does least privilege mean for Agentforce agents?

That each agent acts within the authorization of the user it is serving rather than with broad service credentials. Salesforce’s architecture guidance notes that user identity is lost by default when an agent calls a downstream service with client credentials, which makes per-user authorization and audit trails impossible, while forwarding the original user token everywhere violates least privilege. Three patterns cover the cases: On-Behalf-Of preserves identity within a trust domain, Server-to-Server deliberately omits it for public data, and In-Task Authorization Code asks the user to authenticate inline with an external provider.

Why does field-level security matter more now?

Because agents add retrieval paths. A field hidden on a page layout but not restricted by permission remains reachable through reports, the API and agent responses, so a layout-based control that passed audits for years can surface the value in a sentence. Field level security in salesforce is also the fastest-rising related search attached to this topic, up around 120 percent over the year to October 2026.