Access Governance

A permission set called ‘Sales Manager’ is already technical debt

JSBC Labs16 September 20268 min read

A job title is not an access requirement

A new Sales Manager joins, so an administrator assigns a permission set named Sales Manager. It contains opportunity access, forecasting, discount approval, report export and several system permissions accumulated over years. The label hides which tasks require the access, which data is exposed and when any of it should be removed.

Job titles are unstable containers. Two people with the same title may manage different regions, products or approval thresholds; one person may temporarily cover another function; and reorganisations rename roles without changing the work. When a permission set mirrors the organisation chart, every business change becomes security refactoring. The better unit of design is a durable business capability.

Make permission sets capability-sized

Name an atomic permission set for what it enables: Approve Standard Discounts, Manage Forecasts, Maintain Product Catalogue or Export Customer Reports. Its object, field, app, custom and system permissions should support that capability and little else. A reviewer can then understand why it exists and reuse it wherever the same task appears, independent of department or title.

Capability-sized does not mean one permission per set. Hundreds of microscopic components create assignment noise and obscure dependencies. Choose a coherent task boundary with one business owner, risk level and reason to change. Permissions always reviewed, granted and removed together probably belong together; independently changing permissions probably do not.

Compose personas with permission set groups

Salesforce positions permission set groups as a way to combine reusable permission sets for a job function or persona. That makes Sales Manager an appropriate group name, not an appropriate atomic permission-set name. The group can assemble forecasting, opportunity management and approval capabilities while the underlying sets remain reusable for regional leads, temporary delegates or operations staff.

Keep the distinction explicit in design documents: permission sets answer ‘what can this identity do?’; permission set groups answer ‘which bundle of capabilities supports this persona?’ A user can receive more than one group, so overlapping responsibilities do not require a bespoke clone. This composition also makes impact analysis possible: changing one capability reveals every persona that includes it.

Use muting as an exception tool, not a design strategy

A muting permission set can disable selected permissions contributed within a permission set group. Salesforce documents this as a way to reuse a capability while tailoring the group—for example, including case-management access but muting Delete for a particular persona. It is useful when the common bundle is sound and one controlled variation is required.

Muting becomes dangerous when every persona needs a different subtraction. Reviewers must mentally calculate the effective result of additions and mutes, and a future change to the underlying set can have surprising reach. If a permission is routinely muted, split the capability or remove the permission from the shared set. Treat each mute as documented policy with an owner and review date, not as camouflage for an over-broad component.

Keep the baseline deliberately small

Salesforce recommends the Minimum Access - Salesforce profile as a best-practice starting point, then adding task access through permission sets and groups. That direction matters because permissions granted by a profile remain part of a user's effective access; a permission set group cannot reliably express least privilege when the baseline already grants broad object and field permissions.

Migrate in evidence-backed slices. Inventory what the profile grants, identify the capability behind each permission, move it into a reusable set and test the intended journey before reducing the profile. Copying a broad profile into a permission set merely changes the container while preserving the ambiguity and privilege.

Do not confuse functional access with record access

Object and field permissions answer whether a user may act on a type of data. Organisation-wide defaults, role hierarchy, sharing rules, teams and manual or programmatic sharing determine which records are visible or editable. A Sales Manager permission bundle should not become a substitute for territory, ownership or sharing design. Combining these questions in one label makes access reviews sound simpler than the platform actually is.

Review both dimensions for each sensitive journey. A user may edit Opportunities but see only records for a region; another may read across regions without exporting or changing them. Write positive and negative tests for the combination. Proving that the intended manager can approve a discount is incomplete unless another manager is denied.

Automate assignment from governed attributes

User Access Policies can grant or revoke permission sets, permission set groups and related access mechanisms when users are created or updated. That is stronger than a joiner checklist because assignment can respond consistently when governed user attributes change. It also creates a practical route for removing access when a person moves team, location or employment status.

Automation only moves the trust boundary. If Department, Manager, Country or worker type is stale or freely editable, a precise policy automates the wrong outcome. Define the authoritative source, values, update timing and exception route for every decision attribute. Keep overlapping criteria understandable, and test grants and revocations before activation.

Design access as a lifecycle

Every assignment needs a reason, owner and removal condition. Permanent capability may follow a stable persona; project access should end with the project; elevated support access should be time-bound and approved; integration access should belong to a named non-human identity with its own narrow capability sets. Salesforce supports expiration dates for permission set and group assignments, which can reduce reliance on somebody remembering to reverse temporary access.

Run periodic reviews against effective access, not merely group names. Look for direct assignments that bypass the intended composition, inactive users that retain licences, capabilities with no business owner, broad permissions inherited from profiles and exceptions that have become permanent. Record why sensitive access was accepted and which compensating controls apply. An access model is governed by its removal discipline as much as its grant process.

Test permissions like production code

Permission metadata travels through the delivery lifecycle and can break a process as decisively as Apex or Flow. Version atomic sets, groups, mutes and policies in source control where supported; review diffs for newly granted object, field and system permissions; and include representative user journeys in deployment testing. Pay special attention to powerful permissions and to managed-package changes that may alter dependencies.

Build a small access regression portfolio for each critical persona: actions that must succeed, records that must be visible, fields that must remain hidden and operations that must be denied. Test with realistic licences and the actual baseline profile. Administrator testing proves configuration exists; it does not prove that least-privilege users can work safely or that unintended users are blocked.

The JSBC Labs view

Salesforce's permission tools support a clean separation of concerns: minimal profiles establish a baseline, capability-based permission sets express reusable tasks, permission set groups compose personas, muting handles bounded variation and User Access Policies automate governed assignment. The platform pieces are available; the architectural work is deciding the boundaries and ownership.

Start by choosing one high-risk or fast-changing persona and decomposing it into capabilities. Name each set for an action, identify the business owner, map record access separately and define grant and removal rules. Measure success through explainability: for any sensitive permission, the team should be able to say which capability grants it, why the user needs it, how it was assigned and when it will be reviewed. If the only answer is ‘because they are a Sales Manager’, the debt is already visible.