Security & Access Control refers to the framework used to protect data and control what users can see, create, edit, or delete within the system. It ensures that the right users have the right level of access to the right data, maintaining both data privacy and system integrity.

Salesforce security is implemented in layers such as Organization-level security, Object-level security, Field-level security, and Record-level security. Together, these controls define how data is shared and restricted across users, roles, and profiles.

Organization-Wide Defaults

Organization-Wide Defaults (OWD) define the baseline level of access users have to records they do not own. It is the most restrictive level of record-level security and acts as the starting point for data sharing in Salesforce.

OWD controls what a user can see by default, and further access is then opened using roles, sharing rules, and manual sharing. It ensures data security by restricting access such as Private, Public Read Only, or Public Read/Write depending on business needs.

Example

A company sets the Case OWD to Private, meaning agents can only see the cases they own. If another agent needs access to a case, it must be shared through a role hierarchy or sharing rule. This ensures sensitive customer issues are visible only to authorized users while still allowing controlled collaboration when needed.

Profiles

Profiles are a core security feature used to define what a user can do within the system. A profile controls object-level permissions, field-level access, app visibility, page layouts, and system permissions. Every user in Salesforce must be assigned exactly one profile, which acts as their baseline access control.

Profiles determine whether a user can read, create, edit, or delete records, and also restrict access to sensitive data fields. While profiles control “what users can do,” they are often combined with roles and sharing rules to control “what users can see.”

Example

In a company, a Support Agent Profile is configured so users can only access Case and Contact objects, with permissions to create and edit cases but not delete them. They are restricted from viewing financial fields like “Revenue” or “Contract Value.” However, a Support Manager Profile has broader access, allowing them to view all cases, access reports, and see sensitive customer data. This ensures each user has access only to the functionality required for their job role.

Permission Sets

Permission Sets are used to extend user access without changing their profile. They allow administrators to grant additional permissions such as object access, field access, app visibility, or system permissions to specific users based on temporary needs or special responsibilities.

Unlike profiles (which are mandatory and define base access), permission sets are optional and additive, meaning they only increase access and do not remove existing permissions. This makes them highly flexible for managing exceptions and role variations without creating multiple profiles.

Example

In a company, all users in the Support Agent Profile can access cases. However, one agent is temporarily assigned to handle escalated VIP customers, so the admin assigns a Permission Set that gives access to high-priority case fields and advanced reports. After the assignment ends, the permission set can be removed without affecting the user’s original profile settings.

Role Hierarchy

Role Hierarchy is a record-level security model that defines how data is shared upward within an organization. It ensures that users at higher roles (such as managers or directors) can access the records owned by users below them in the hierarchy, based on business reporting structure.

Role hierarchy is primarily used for data visibility and reporting access, not for user permissions. It helps managers view and manage the work of their team members by automatically granting access to subordinate records.

Example

In a company, a Support Agent works under a Support Team Lead, who in turn reports to a Support Manager. If the Role Hierarchy is configured accordingly, the Support Manager can automatically view all cases owned by agents and team leads under them. So, if a customer case is created by an agent, the manager can still access it for monitoring, escalation, or reporting purposes without any manual sharing.

Sharing Rules

Sharing Rules are used to extend record-level access to specific groups of users when Organization-Wide Defaults (OWD) are set to restrictive levels. They automatically grant additional access to records based on criteria such as record owner or field values, without changing ownership.

Sharing rules help ensure controlled collaboration by opening up data visibility for teams that need access, such as support teams, sales teams, or cross-functional groups.

There are two main types of sharing rules:

• Owner-based sharing rules (based on record owner)
• Criteria-based sharing rules (based on field conditions)

Example

In a company, Case OWD is set to Private, so agents can only see their own cases. However, a sharing rule is created to give the Escalation Team access to all cases where Priority = High. Now, whenever a high-priority case is created, Salesforce automatically shares it with the escalation team, allowing them to view and work on urgent issues without changing the case owner.