Moving Salesforce access from profiles to permission sets

A user still has one Salesforce profile, but most functional access is easier to manage through permission sets and permission set groups. The profile provides the baseline; additional access can then be assembled around the work a user performs instead of creating another profile for every variation.

This is not a mechanical conversion. Permission sets grant access and generally cannot remove access already provided elsewhere. If a broad profile remains in place, adding a cleaner permission-set structure does not reduce the user's effective permissions.

Know what is being separated

• Profile: the user's baseline identity settings and access, including items that still remain profile-specific.
• Permission set: additional permissions for a job, task, feature or managed package.
• Permission set group: a maintained bundle of permission sets commonly assigned together.
• Muting permission set: permissions removed from one permission set group; it does not revoke access granted by the profile, another group or another permission set.
• Permission set licence: a licence boundary that may be required before certain product permissions can be assigned.

Inventory the current model

Start with users and assignments, then inspect the permissions behind them. Include inactive users and integration identities so legacy access does not quietly survive the redesign.

SELECT AssigneeId, Assignee.Username, PermissionSetId,
       PermissionSet.Name, PermissionSetGroupId
FROM PermissionSetAssignment
ORDER BY Assignee.Username

SELECT ParentId, SObjectType, PermissionsRead, PermissionsCreate,
       PermissionsEdit, PermissionsDelete, PermissionsViewAllRecords,
       PermissionsModifyAllRecords
FROM ObjectPermissions
WHERE ParentId IN (
  SELECT Id
  FROM PermissionSet
  WHERE IsOwnedByProfile = true
)

Object permissions are only one layer. Review field permissions, system permissions, Apex class and Visualforce access, custom permissions, app visibility, record types and other settings relevant to the org. Record access also depends on roles, sharing, teams and ownership, so it should not be inferred from permission metadata alone.

Find patterns worth keeping

Map users to real work rather than copying profile names. An access catalogue might include a small baseline, a sales-core set, a case-management set, an approval set and a tightly controlled administration set. The names should explain the capability being granted.

• Identify permissions genuinely shared by most users on the same licence.
• Separate common job access from temporary or high-risk tasks.
• Find duplicate permission sets and profiles that differ by only a few settings.
• Record the owner and business reason for each proposed permission set.
• Document mutually exclusive or licensed capabilities that cannot be grouped freely.

Design for least privilege and explainability

Keep the baseline profile as narrow as the organisation can support, then use permission sets for named capabilities. Permission set groups are useful for common job bundles, but the individual sets should remain coherent enough to understand and reuse.

• Prefer one clear current permission set over duplicate old and new versions.
• Do not mix everyday user access with powerful deployment, data-export or configuration permissions.
• Use time-bound assignment processes for temporary elevated access where the operating model supports them.
• Keep managed-package permissions distinct when ownership and licence constraints differ.
• Treat integration users as separate identities with access designed around the integration, not a human job title.

Migrate one operating group at a time

1. Choose a contained user group with representative day-to-day work.
2. Record its current effective access and critical user journeys.
3. Create the target baseline and permission assignments in a controlled environment.
4. Test what users must be able to do and what they must no longer be able to do.
5. Pilot with named users and a documented recovery route.
6. Move the wider group after the evidence is reviewed.
7. Remove the replaced profile permissions or retire the old profile pattern so both models do not remain active indefinitely.

Operate the model after migration

• Route access requests through an owner who understands the business capability being granted.
• Review powerful permissions, inactive assignments and exception users on a defined cadence.
• Use source control and peer review for permission metadata changes.
• Retire superseded sets instead of adding another similarly named version.
• Re-test representative users after Salesforce releases, licence changes and major package updates.

A well-run access model lets an operations owner explain why a user has a capability, a developer review the metadata change and the organisation remove access without guessing which profile variation supplied it.