Salesforce permission concept with permission sets
A Salesforce permission concept defines what every user may do and which records they see. Today I build it with one lean base profile per licence type, permission sets per function and permission set groups per role. Profiles only carry what exists nowhere else, such as login hours and IP ranges. When several partners work on the org, each stream delivers the permission sets for its features, and the client decides which role gets which sets. That keeps the concept readable, even after the third change of partner.
Which two layers does a permission concept have?
Many concepts mix two questions that Salesforce answers separately:
| Layer | Question | Tools in Salesforce |
|---|---|---|
| Permissions | What may the user do? Which objects, fields, apps and functions? | Profile, permission set, permission set group |
| Visibility | Which records do they see? | Org-wide defaults, role hierarchy, sharing rules, teams |
A field service technician, for example, may edit work orders (permissions) but only sees the work orders of their region (visibility). A dealer in the portal may create warranty claims but only sees the assets of their own customers. If you mix both layers in one document, you will not find out later why a user sees something they should not.
Profiles or permission sets?
Every user has exactly one profile and any number of permission sets. For a long time almost all permissions lived on the profile. I know the result from many grown orgs: every combination of country, department and special case gets a new profile, until there are thirty of them that differ in small details.
In 2023 Salesforce announced it would retire permissions on profiles with Spring ’26 (Salesforce Admins blog1). Salesforce later did not enforce that date (Salesforce Ben2). So profiles keep working. The direction is still clear: new features arrive for permission sets and permission set groups, not for profiles. That is why I treat profiles like change sets: they still work, but nobody should build anything new on them.
Base profile, permission sets and groups per role
I build it in three layers:
- One base profile per licence type. One profile for internal users, one for portal users, one for integration users. It contains only what every user of that type needs, plus login settings. Salesforce provides the “Minimum Access - Salesforce” profile as a starting point.
- Permission sets per function. One set for “create quotes”, one for “dispatch work orders”, one for “review warranty claims”. A set describes a capability, not a person.
- Permission set groups per role. The role “inside sales Germany” bundles the sets this role needs. If a role explicitly must not have a permission from one of the sets, a muting permission set removes it within that group.
Users then get a base profile and one or two groups. The assignment can be automated with user access policies, for example based on department or country on the user record. When an employee moves from sales to service, you swap a group instead of a profile with a hundred differences.
I plan visibility separately. For manufacturers with subsidiaries in many countries it usually starts with a simple question: may sales in France see the customers in Germany? If the answer is no, the org-wide default for accounts is private and the role hierarchy reflects countries and regions. Exceptions, such as a key account manager for a group customer across several countries, are handled with sharing rules or account teams. This decision belongs in the concept early, because changing it later takes a lot of testing.
Integration users get their own rule: one user per interface, one permission set with exactly the objects and fields that interface reads or writes. An integration user with “Modify All Data” is the biggest risk in many orgs, because nobody knows any more what it is allowed to do.
How does the concept stay clean when several partners build?
With several partners the mess rarely comes from bad intent. Each partner quickly needs a permission for their feature, and the fastest way is to extend an existing profile. After a year nobody can say which permission belongs to which feature.
I consider these rules the minimum:
- Every stream delivers its own permission sets. The set carries the stream in its name, such as
FS_DispatcherorSALES_Quote. Which stream owns which object is defined in the object ownership matrix. - Partners do not change profiles or groups. The client decides which role gets which set. A pull request that changes a profile or a group needs approval from the client side.
- Permissions go through review. Permission sets are metadata in the repository and show up in the pull request like code. The reviewer checks whether a new permission is really needed, especially “View All”, “Modify All” and system permissions. More on that in why pull request reviews are a must.
- A role matrix owned by the client. A table with roles in the rows and permission sets in the columns. It is the business truth; the groups in Salesforce are the technical implementation.
For admins
How do I migrate from many profiles to permission sets?
Salesforce offers the free User Access and Permissions Assistant, which analyses existing profiles and can move permissions into permission sets. - First collect the permissions that all profiles of one licence type share and put them into the base profile. - Then move the differences into permission sets per function and bundle them into groups. - Switch users step by step, country by country, and only delete the old profiles once nobody uses them.
Take stock of profiles and system permissions
Start with an inventory: how many profiles exist, how many users hang on each one, and which integration users have system permissions such as “Modify All Data”? Then write down the role matrix before you rebuild anything in Salesforce. From now on new features only get permission sets. The migration of the old profiles can follow role by role. For the first number, a user report grouped by profile is enough. Each integration user then gets its own permission set with exactly the objects its interface reads or writes. How I set this up on the client side is described under Salesforce architecture on the client side.
Sources2
- 1Salesforce Admins blog (opens in a new tab)admin.salesforce.com
- 2Salesforce Ben (opens in a new tab)salesforceben.com
Frequently asked questions
What is the difference between a profile and a permission set?
Every user has exactly one profile but any number of permission sets. Both can grant object, field and system permissions; settings such as login hours and IP ranges only exist on the profile.
Is Salesforce retiring permissions on profiles?
Salesforce had announced the end of permissions on profiles for Spring '26 and later did not enforce that date. The recommendation stays the same: grant new permissions through permission sets and permission set groups.
What is a permission set group?
A permission set group bundles several permission sets into one role, for example inside sales Germany. A muting permission set in the group removes single permissions again without changing the sets themselves.
Who should own the permission concept?
The client. Partners deliver the permission sets for their features, but who gets which role and which permissions a role bundles is decided by the client and checked in the pull request review.