Security Architecture
Salesforce security starts with data classification—not permission sets
Permission configuration is not the starting point
Salesforce security reviews often begin in Setup: profiles, permission sets, roles, sharing rules and a long spreadsheet of who can see what. Those controls matter, but starting there creates a false sense of precision. If the organisation has not identified which fields contain sensitive data, why that data exists and who owns the decision to expose it, the access model is being built on assumptions.
The result is usually one of two extremes. Teams grant broad access because the business rules are unclear, or they lock the system down so aggressively that users create spreadsheets and side channels to do their work. Neither is least privilege. Least privilege is the smallest access required for a defined purpose, which means the purpose and the data must be understood before the permissions can be designed.
Classify the field, not just the object
An Account record is not uniformly sensitive. A company name may be widely usable, while bank details, identity information or commercial terms on the same record require tighter controls. Salesforce supports field-level data classification, including sensitivity and compliance categorisation. Used properly, that metadata gives architects a basis for access, retention, reporting, masking and audit decisions.
Start with the fields that create the greatest consequence if exposed or altered. For each, record a business owner, sensitivity level, applicable regulation or contractual obligation, retention need and approved purposes. Also identify derived data: a harmless-looking score or segment may reveal a sensitive conclusion even when the source fields are protected. Classification should follow meaning, not merely the API name or object boundary.
Design access as a set of layers
Salesforce access is the combined result of several layers. Object permissions decide whether a user can act on a type of record. Field-level security controls which attributes are available. Organisation-wide defaults, role hierarchy, teams, territories and sharing mechanisms determine record-level reach. Restriction rules can narrow record visibility for supported scenarios. A page layout is presentation; it is not a security boundary.
Review the effective combination rather than approving each component independently. A permission set that appears narrow may become excessive when combined with another assignment and a generous sharing rule. Broad permissions such as View All or Modify All deliberately bypass normal record sharing for an object, while View All Data and Modify All Data are wider still. These are operational tools for tightly controlled roles, not convenient remedies for access tickets.
Model personas around responsibilities
Job titles are a poor foundation for durable security. Two sales managers may work in different regions, handle different customer categories or carry different approval authority. Define access personas around responsibilities and data purposes: service agent, regional sales manager, finance approver, integration operator or support investigator. Then assemble permission sets and groups around reusable capabilities rather than copying one large profile for every variation.
Every exception needs an owner and an expiry condition. Temporary elevated access that never expires becomes permanent privilege by neglect. Joiner, mover and leaver processes should remove obsolete assignments as reliably as they add new ones. A technically elegant permission model still fails if identity lifecycle processes allow access to accumulate faster than it is reviewed.
Execution context is part of the security contract
Custom automation can cross the boundary users experience in the interface. In Apex, record sharing and object or field permissions are separate concerns. Salesforce recommends explicitly declaring sharing behaviour and explicitly choosing user or system access modes for database operations so that the intended contract remains clear across API versions. For graceful handling of inaccessible fields, Security.stripInaccessible can remove fields the user is not permitted to access.
Flow also has different execution contexts depending on how it is launched and configured. System context can be necessary for controlled background operations, but it must be a deliberate exception. Document what elevated operation is required, which fields it may touch and what prevents a caller from using that elevation for an unintended purpose. Hiding an input on a screen or omitting a field from a layout does not secure a privileged automation path.
Integration and agent identities need smaller blast radii
A shared administrator account is not an integration strategy. Give each material integration a dedicated identity with only the objects, fields, records and API capabilities it needs. Separate read and write responsibilities where the risk warrants it, keep credentials out of code and make the identity visible in audit trails. When one connection is compromised, its permissions define the potential blast radius.
The same principle matters more as agents can initiate actions across systems. Salesforce's architecture guidance recommends dedicated least-privilege identities for event-triggered agent sessions rather than high-privilege administrator identities. An agent's action set should be constrained by platform permissions and trusted server-side validation, not only by natural-language instructions. Prompts guide behaviour; authorisation controls capability.
Test effective access and monitor drift
Test security as representative users, including negative scenarios. Confirm that restricted users cannot query a field through Apex, invoke an elevated action, export an inappropriate report or reach a record through an unexpected sharing path. Test integrations with their real permission sets. Administrative testing proves that a feature works; persona testing proves that it works without exposing more than intended.
Then review the model continuously. Track broad permissions, inactive users, unexpected permission-set combinations, high-volume exports and changes to sharing configuration. Revisit classifications when new integrations, AI use cases or regulatory obligations appear. Security architecture is not a one-time hardening exercise because the meaning, movement and use of data keeps changing.
The JSBC Labs view
A strong Salesforce security model begins with a data conversation, not a Setup screen. Classify sensitive fields, name their owners and define approved purposes. From there, design layered access for clear personas, make elevated execution explicit, isolate machine identities and test the effective result.
Permission sets are the implementation mechanism, not the policy. When the policy is absent, configuration grows by exception and privilege accumulates invisibly. When data classification and accountability are clear, least privilege stops being a slogan and becomes an architecture the organisation can explain, test and maintain.