Permissions and Security¶

Standards for permissions metadata: profiles, permission sets and groups, sharing, and the high-risk permission elements that warrant blocking review.

Every standard on this page applies the principle of least privilege (PLP): a user holds the access that their work requires, and nothing more. NIST defines it as the principle that a security architecture is designed so that each entity is granted the minimum system resources and authorisations that it needs to perform its function (NIST glossary: least privilege), and makes it a control of its own, AC-6, in NIST SP 800-53. Salesforce's own guidance says the same of an org: grant the minimum level of access that each user, integration, and automated process needs, and grant it through permission sets and permission set groups rather than profiles (Well-Architected: Trust).

Object Level Security¶

• Every object's org-wide default is Private, for internal users and for external users, so that a user sees a record only when ownership, the role hierarchy, or a sharing rule gives access (The Principle of Least Privilege). A public default opens every record of the object to every user who can read the object, and an external one opens them to external users, such as the members of an Experience Cloud site. A default that the platform controls, such as Controlled by Parent on the detail object of a master-detail relationship, is allowed. A custom or standard object whose internal or external default is anything else, such as Public Read Only or Public Read/Write, blocks the pull request (severity 1). Enforced by NonPrivateCustomObjectSharing and NonPrivateStandardObjectSharing.

Record Sharing¶

TODO: Sharing settings and sharing rules

• An autolaunched Flow that a with sharing Apex class launches enforces the sharing rules of the class's user only when the Flow runs on API version 62.0 or later, in the default context. At an earlier version it runs without sharing and can read and change every record. The standard is in Automation: Flow Security.

Field Level Security¶

Profiles, Permission Sets, and Permission Set Groups¶

Access is granted through permission sets and permission set groups, and a profile grants none (The Principle of Least Privilege).

Each of the two holds things that the other cannot. Only a profile holds its user licence, login hours and login IP ranges, page layout assignments, and its users' default settings, such as the default app and the default record type (Profiles, Well-Architected: Trust). Only a permission set can be combined with others in a permission set group, be assigned to a user who already has several, have an assignment that expires on a set date (Set Assignment Expiration Details), and apply to one session alone (Session-Based Permission Sets).

• Every user except a system administrator is on a custom profile that grants no permissions. Ideally all of them are on the same profile. A profile belongs to one user licence, so an org with more than one kind of licence has one such profile for each.
• All permissions are granted through permission set groups. A group stands for a persona, with roughly one group for each persona, and is made up of several permission sets.
• A permission set is assigned directly to a user only for a specific situation, such as a temporary bypass.
• A custom permission is granted through a permission set, since a profile grants nothing. A user who needs one for a time, such as a bypass (Automation: Global Bypass), is assigned its permission set directly, and the assignment is removed when the need has passed.
• An assignment that grants a sensitive permission is given an expiry date (Set Assignment Expiration Details). No rule can check this, because an assignment is a record in the org and not a file in version control (Configuration Data). It is a policy for each organisation to set.

No rule checks the other standards. Reviewers do.

High-Risk Permission Elements Within Profiles and Permission Sets¶

Profiles and Permission Sets are already classified as Tier 1 metadata types. However, the pipeline should apply additional scrutiny specifically to changes that enable high-risk user permissions, regardless of which Profile or Permission Set contains them. The following should be treated as immediate blockers:

The two severities are treated differently, as Accepting a Blocking Violation sets out. A severity 1 grant is removed, and an approval past it is almost never given. ViewAllData and ModifyAllData have one exception: an integration user may need one of them, and senior reviewers approve that grant. A severity 2 grant, View All or Modify All on a single object, is removed unless the owning team accepts the case for it.

The standards apply to permission sets and to custom profiles. A standard profile is managed by the platform and is not checked. A profile is checked as custom only when its file sets custom to true.

Rules¶

The rules that this page mentions. The Standard column gives each rule's standard in one line, and the Section column links to the section that mentions the rule; "Not yet written" marks a rule of this page that no section mentions yet. Appendix F.6 holds the full cross-reference.

Organisations may wish to add their own rules, and this list should grow as more rules and standards are developed.