Security model: profiles, permission sets and sharing

A Salesforce org holds sensitive data: customers, deals, support cases. Not everyone should see everything. A barista at Brew & Bean should see today's orders, but not the owner's sales figures. A manager should see their team's orders but not another shop's.

Salesforce answers this with security in layers. Each layer can only narrow or widen what the previous layer allows, so you design from the tightest setting outwards.

Think of a building. The org and login layer is the main gate. Object permissions decide which floors you can enter. Field-level security decides which cabinets you can open in the room. Record-level sharing decides which individual folders in those cabinets are yours to read.

A profile is a set of permissions assigned to a user. Every user has exactly one profile. It decides, among other things, object permissions (often called CRUD: Create, Read, Edit, Delete), which apps and tabs they can open, and which fields they can see.

A permission set is a bundle of extra permissions. A user can have many, and they only add access. A permission set group combines several permission sets into one package for a job role (for example, Barista or Shop Manager). A group can also include a muting permission set that switches off selected permissions in that group.

The current guidance from Salesforce is: give users a minimum-access profile, then grant what they need through permission sets and groups. This keeps the number of profiles small and access easy to review. Salesforce has been moving permission management away from profiles, so check the release notes and Help for your org's version.

Field-level security (FLS) is set on a field. In Object Manager, open the object, then Fields & Relationships, open the field and click Set Field-Level Security. For each profile you tick Visible and Read-Only. A field that is not visible is hidden from page layouts, reports and the API for that user. Hiding a field on a page layout is not security; FLS is.

Object permission says "you may read Coffee Orders". Record-level sharing says "which orders?". It starts closed and opens up. The ordering is important:

A good rule: set the OWD to the most restrictive level any user needs, then open access up with roles and sharing rules. You can never use sharing to restrict below the OWD.

Roles are not profiles. A profile says what you can do (objects, fields, system features). A role says where you sit in the data-visibility hierarchy. Many mix them up in interviews. A simple test: if the question is "which records?" think role and sharing. If it is "which objects and fields?" think profile and permission sets.

View All and Modify All on an object let a user see or edit every record of that object, ignoring sharing. View All Data and Modify All Data do the same across all objects. Give these only to the people who truly need them, such as integration users or administrators.

Apex code can ignore sharing unless a class is declared with sharing. Developers must choose this deliberately; the Apex lessons cover it.

Common questions: "Profile versus permission set?", "What are org-wide defaults?", "Role hierarchy versus profile?", "How would you let a user see records they do not own?" and "Can sharing rules restrict access?" (No, they only widen it.) Practise answering with an example such as the Brew & Bean one above, in three short sentences.

I'm designing Salesforce security for [business, e.g. a chain of 5 coffee shops].

Users: [roles, e.g. baristas, outlet managers, head office finance].
Objects: [list of objects].
Rules: [who should see what, e.g. baristas only see their outlet's orders].

Propose org-wide default settings for each object, a role hierarchy, the permission sets (with object and field access) and any sharing rules. Put the answer in a table and explain each choice in one line.

What to expect: Check that the answer uses OWD as the baseline and only widens with roles and sharing rules. If it suggests sharing to restrict access, it is wrong.