The Basic Question: What Governs User Access
When someone asks, "How did a user get access to this field?", the correct answer is almost always a combination: their Profile determines baseline access, assigned Permission Set Groups add role-based capabilities, and sometimes a single, additional Permission Set handles a specific exception. The practical problem is that most organizations build this combination in reverse—starting with a broad Profile that contains almost everything, then "fixing" specific issues with individual permissions that no one remembers to remove.
A healthy permission model is built in the opposite direction: a Profile that is as narrow as possible, primarily defining licensing, default app access, and login characteristics; and all actual work capabilities—which objects, which fields, which actions—are moved to Permission Sets and Permission Set Groups. It's important to clarify: this article focuses solely on Object, Field, and System Permissions. Questions about record visibility between users—OWD, Role Hierarchy, Sharing Rules—are discussed in the Visibility and Sharing Guide, as this is a separate decision layer with its own trade-offs.
The Three Units and Each's Role
| Unit | What it Determines | How Many a User Can Have | When to Choose It |
|---|---|---|---|
| Profile | Licensing, default App Visibility, Page Layout, Login Hours/IP | Exactly one | Infrastructure differences between user types |
| Permission Set | Object, Field, Apex Class, Tab permissions - additive only | As many as needed | A single capability relevant to some roles |
| Permission Set Group | Bundling several Permission Sets under one name, with Muting capability | As many as needed | A fixed combination of permissions representing a complete job role |
The difference between a Permission Set and a Permission Set Group is not just technical—it's organizational. A single Permission Set is suitable for one focused capability ("Access to Financial Reports"). A Permission Set Group is suitable when you want to assign a complete "work package" to a department or role and maintain it in one place as it changes.
Decision Framework: Where a New Permission Belongs
When a request arises to add access, the first question isn't "which Profile to add it to" but rather to which unit the permission structurally belongs:
- Is this a permission characteristic of all users with the same license type? If so, this is a place for a Profile, provided it applies to all license holders and not a sub-group.
- Is this a work capability that a specific role group always needs along with other permissions? If so, this is a place for a Permission Set Group, even if it needs to be broken down into several separate Permission Sets first to allow flexible combination.
- Is this a specific and temporary permission for a single user or an exception? If so, an independent Permission Set, manually assigned and reviewed during periodic audits.
- Is the permission meant to revoke something from a specific user within a broad group? This is where a Muting Permission Set within a Permission Set Group comes in—the only tool in Salesforce that allows reducing a permission without touching the Profile or disassembling the group.
The rule that prevents most drift: Never edit a Profile to solve a single user's problem. If the fix is defined as an exception, it goes through a Permission Set that is documented and has an audit date.
Checklist for Building a Permission Model from Scratch
- ☐ Actual job roles (not organizational departments) have been mapped, and each role has a clear name.
- ☐ For each role, a list of required capabilities at the object, field, and Apex Class level has been defined.
- ☐ Focused Permission Sets have been built for single capabilities, not generic "permission piles."
- ☐ Each role has been assigned one Permission Set Group that consolidates relevant capabilities.
- ☐ Profiles have been narrowed down to licensing and infrastructure differences only.
- ☐ A process has been defined for exception cases: who approves a specific Permission Set and for how long.
- ☐ An audit cadence (at least quarterly) has been established to compare active permissions against the current role.
- ☐ A single owner has been designated for maintaining the permission model in response to organizational structure changes.
Organizational Scenario: An Insurance Company with Three Sales Units
Imagine a mid-sized insurance company with about three hundred Salesforce users, divided into three units: direct sales, agent sales, and claims. Before the project, the company had twelve different Profiles, some almost identical copies created to "fix" a single permission for a small group. A typical result: when a new agent joined, no one knew for sure which of the twelve Profiles was suitable for them, and the actual answer was "copy from someone similar."
The architectural team rebuilt the model: only three Profiles, based on license type (full Sales Cloud, Community for external agents, Service Cloud for claims). Above them, seven Permission Set Groups according to actual job roles—sales representative, sales team manager, external agent, agent manager, claims examiner, claims manager, and a bridging role that handles both sales and claims. Each Permission Set Group was composed of focused Permission Sets like "Access to Active Policies" or "Approve Refunds up to a Defined Limit," so they could be recombined when a new role was created without building permissions from scratch.
The measured outcome: the time to onboard a new user dropped from several days (which included manual checking of the appropriate Profile) to a few hours, and the number of support requests such as "I don't have access to field X" decreased by half in the quarter following the transition, because most of these requests stemmed from a Profile that did not include the capability, and it was unclear whom to contact for a fix.
Common Risks and Preventive Actions
| Risk | How it Appears in Practice | Preventive Action |
|---|---|---|
| Profile becomes an ad-hoc fix tool | Proliferation of almost identical Profiles, each for a small group | Move all specific permissions to a Permission Set and narrow Profiles to licensing only |
| Inconsistent Field-Level Security | The same field is exposed in one place and blocked in a parallel place | Document a central FLS matrix for every sensitive field and review it in each release |
| "Sticky" permissions after a role change | A user who changed roles retains permissions from the previous role | Offboarding-from-role process that removes old Permission Set Group before adding a new one |
| Overly broad System Permissions (View All Data, Modify All) | Granted "to save time" and not removed afterwards | Dedicated approval and expiration date for all broad system permissions |
| Lack of ownership for the permission model | Each team adds permissions without an overall view | Single owner who approves every new Permission Set or Group before deployment |
Metrics for Model Health Assessment
| Area | What to Measure | Review Cadence |
|---|---|---|
| Unnecessary Duplication | Number of active Profiles compared to the number of actual license types | Quarterly |
| Permission Accuracy | Percentage of users whose permissions match their documented HR role | Quarterly |
| Open Exceptions | Number of specific Permission Sets without a review date | Monthly |
| Broad Permissions | Number of users with View All Data / Modify All Data without documented justification | Monthly |
| Onboarding Time | Average time from new access request to full allocation | Continuous |
For the initial version of tracking, it is advisable to use three out of the five metrics and expand only after a reliable baseline is established. A metric without an owner and a review date tends to disappear from the report after the first month.
How it Integrates into the Broader Architecture
A good permission model is a prerequisite, not a substitute, for planning record visibility (OWD, Role Hierarchy, Sharing Rules)—these two topics are complementary but resolved separately. An organization that tries to solve a visibility problem by expanding a Profile, or vice versa, usually finds the solution brittle as soon as the organizational structure changes. When the organization moves between multiple Orgs and a single Org, the permission model is one of the things that needs to be remapped—an expansion on this topic appears in the Single Org vs. Multi Org Guide. And when the permission itself depends on complex conditional logic, it's worth considering whether the implementation belongs in Flow or Apex, as detailed in the Flow vs. Apex Guide.
In organizations running event-driven processes between systems, it's important to ensure that the permissions of service users (Integration Users) are built on the same principle—a focused Permission Set and not a broad Profile with "System Administrator" as a convenient default. This topic connects to the broader planning of inter-system communication, described in the Salesforce Event-Driven Architecture Guide.
Summary
A permission model that stands the test of time is built from the bottom up: focused capabilities in Permission Sets, assembled according to real job roles in Permission Set Groups, and a Profile that maintains a minimal role of only licensing and infrastructure. The clear sign of failure is a proliferation of Profiles created to solve specific problems—each additional Profile of this kind is a debt that accumulates until no one remembers why it exists. When internal capacity is lacking to build or clean up an existing model, CRM Architecture services offer a practical path to a focused start.