Original OrbTrail analysis expanded with complementary research, practical context and verified references.
Salesforce cancelled the retirement of permissions in profiles, according to a support note published on June 6, 2026. An August 14 Salesforce Ben article turns that change into a more useful operating question: if the platform will no longer force migration, how should access be distributed without returning to proliferating profiles and per-user exceptions? The official answer remains largely unchanged. Salesforce says profiles will not receive further investment and recommends a permission set- and permission set group-led model. Cancellation removes the end-of-life date; it does not turn a monolithic structure into a modular solution.
The distinction matters because every user is still associated with one profile, while permission sets can be reused and combined. When an organization clones profiles to represent job, region, product and exception, each change must be repeated across several copies. With granular sets, one capability can participate in different groups without duplicating its definition. OrbTrail frames the central answer this way: a profile should be the smallest viable starting point; a permission set should represent a testable capability; a permission set group should assemble the package needed by a persona or job; and a policy should determine when that composition enters and leaves a user's account.
This design is not automatically simple. Splitting one enormous profile into dozens of poorly named sets merely moves the confusion. Value appears when the organization has a stable taxonomy, an owner for every capability, observable grant criteria and a review process. The architecture must answer four questions without manual investigation: what does this set grant, which group reuses it, why did this person receive it, and when is the access no longer needed? If any answer depends on an administrator's memory, the organization still operates through exceptions even if every metadata component is a permission set.
Keep profile-only controls in the profile
App and record type defaults, layouts, login hours and IP ranges remain in the mandatory layer.
Model reusable building blocks
Separate reading, execution and sensitive privileges so each block has a clear purpose and owner.
Compose work, not the org chart
Group capabilities needed for tasks; use muting only to reduce a set inside that particular group.
Grant, expire and revoke by criterion
Access policies and expiration turn job changes and temporary privileges into auditable events.
A minimum profile is a boundary, not a new universal profile
Salesforce guidance separates two configuration types. The profile retains items that still depend on it: app and record type defaults, page layout assignment, login hours and login IP ranges. System, object and field permissions, connected app access, Apex classes, Visualforce pages, tabs and custom permissions should move to permission sets where the platform supports it. For a new implementation, the official reference recommends starting with the Minimum Access Profile. That does not mean placing every user on one profile without considering licenses, experiences and login controls; it means preventing the profile from accumulating capabilities that can be composed elsewhere.
A useful decomposition follows the work. Salesforce's How I Solved It article proposes a Base layer for common permissions without object or field access, a Read layer for navigating and reading an app without sensitive data, and a Persona layer for everything else specific to that job. It is not a universal standard, but it demonstrates an important property: the same Read set can serve Marketing and Sales while each persona receives only its particular privileges. Scarce capabilities—publishing Knowledge, approving payments or administering an integration—can remain task-oriented sets without contaminating an entire persona group.
Muting reduces one group; it does not revoke access granted elsewhere
Permission set groups calculate the union of their included sets. A muting permission set can suppress a permission inside that specific composition, making it easier to reuse a broader set across personas. The boundary is crucial: the mute affects only that group. If the same user receives the permission through a profile, another permission set or another group, it remains effective. Muting must therefore not be treated as a global deny or a substitute for discovering every grant path. Before relying on it for a sensitive field or Modify All, a team needs to verify the user's combined access.
That behavior also changes the granularity decision. Building one giant set and muting dozens of items in every group creates a matrix that is difficult to review; building one set per field creates an inventory that is impossible to govern. The balance is a cohesive capability whose components share similar risk and change together. A Read — Service Console set can combine the app, tabs, objects and nonsensitive fields required for navigation. Exporting reports, viewing encrypted data or running a privileged action deserves separate blocks because ownership, approval and expiration can differ.
Real scale begins when a job change also removes access
User Access Policies are generally available and can grant or revoke permission sets, permission set groups, package licenses, permission set licenses, public groups and queues. An automated policy can run when a user is created or updated; a manual policy can migrate a population in a controlled operation. Trailhead documents filters over user attributes and ordered actions, plus a recent-access-changes history. That makes it possible to connect access to observable criteria—job, department, status or another governed attribute—instead of maintaining an informal list of people.
The decisive test is an internal transfer. When someone leaves Sales for Operations, automation must remove the previous package and grant the new one, not simply accumulate access. Temporary grants call for Assignment Expiration on permission sets or groups so the privilege ends without a future ticket. In a sandbox, teams should simulate hiring, promotion, lateral transfer, leave and termination; check compatible licenses; wait for group recalculation; and validate effective access rather than assignment presence alone. Production should receive the same script, owner and rollback evidence.
Cancellation should end the deadline race, not the privilege-reduction program
The cancellation note recommends continuing to adopt permission sets, permission set groups, User Access Policies and sandbox testing. Salesforce Well-Architected goes further: it calls for modular sets, groups aligned to business capabilities, minimally used profiles and a security matrix connecting people and systems to personas. This turns migration from a technical project into an access operating system. Useful indicators become coverage through governed groups, unjustified direct assignments, elevated privileges with and without expiration, users outside the matrix and time to remove access after a job change.
OrbTrail's conclusion is deliberately less dramatic than the announcement: no organization needs to migrate because a retirement date is approaching, but mature organizations still need to explain access reproducibly. Start with one persona and one risky capability, capture current effective access, assemble the minimum profile and required blocks, automate grants and revocation, test all five lifecycle events, and only then repeat. The architecture is working when a new task means composing a governed block—not cloning another profile or giving one person a permission forever.
