Security & access

An account exec once forwarded me a report showing every customer’s negotiated discount, contract value, and renewal date across the entire company, including deals two levels above his pay grade. He was not malicious, he was curious, and the org had handed him “View All Data” as part of a profile someone cloned in 2019 and never audited. One checkbox, buried in a profile nobody remembered building, exposed the commercial terms of the whole book to anyone who inherited that profile. Security and access is where a single wrong default is not a bug you fix later. It is a disclosure you cannot take back, because the person has already seen the number.

Access control gets treated as an admin chore, a box to tick during onboarding. It is closer to the blast radius setting for every other mistake in the system. A bad automation touches the records a user can reach. A curious rep sees the fields a profile exposes. Least privilege is not paranoia: it is the practice of making the blast radius as small as the job allows, so that when something goes wrong, and it will, the damage is contained to what that person actually needed.

Profiles set the floor, permission sets add on top

Every user has exactly one profile, and it should grant the minimum every holder of that profile needs. Anything extra rides on a permission set, assigned to the individuals who need it. This is the model Salesforce has pushed toward for years, and the reason is maintainability: a per-person capability layered as a permission set is visible, additive, and removable, where the same capability baked into a cloned profile is invisible and spreads to everyone who ever inherits the clone.

The anti-pattern is the “kitchen-sink profile,” cloned once, granted everything to avoid future tickets, then handed to people who need a tenth of it. That is how a rep ends up with View All Data. Keep profiles thin, push variability to permission sets, and use permission set groups to bundle the sets a role needs so assignment stays one action instead of ten.

The sharing model controls which records, FLS controls which fields

Two separate questions hide behind “who can see this.” Record access (which rows a user can open) is governed by org-wide defaults, role hierarchy, and sharing rules. Field-level security (which columns a user can see or edit on a row they can already open) is governed by FLS on the profile or permission set. Confuse them and you either lock reps out of their own accounts or expose a discount field to the whole company.

Set org-wide defaults to the most restrictive posture the business tolerates (Private for Opportunity is common), then open access back up deliberately with the role hierarchy and sharing rules. Opening up from Private is auditable. Clamping down from Public is a fire drill, because you have to find everyone who already saw what they should not have.

FLS is also the enforcement behind the one-writer-per-field rule from data governance. If enrichment owns employee count, FLS lets only the integration user’s profile write it and locks reps to read-only, so reps cannot fight the enrichment tool. A validation rule makes the intent explicit for the cases FLS alone cannot express.

// Sensitive commercial field: only Deal Desk edits the approved discount.
// Everyone else is read-only via FLS; this backstops it in automation.
AND(
  ISCHANGED( Approved_Discount__c ),
  NOT( $Permission.Can_Edit_Approved_Discount )
)

Security and access is the one area where the cost of getting it wrong is asymmetric: a too-tight setting is a support ticket, a too-loose one is a disclosure you cannot reverse. Keep profiles thin and add capability with permission sets, separate record access from field access in your head and in the config, default to Private and open up deliberately, and hunt down View All Data before anything else. Grant the least the job needs, review it on a cadence, and the blast radius of every other mistake shrinks to the size of one person’s actual work.