Configuring Salesforce Security — A Step-by-Step Process
Salesforce security can seem daunting at first. It’s a robust system with many components, reflecting its flexibility in handling a wide range of data access and sharing scenarios.
For organizations using Salesforce primarily as a CRM, the default configuration typically meets most needs, with only minor adjustments to the role hierarchy. However, due to its complexity, developing a practical and comprehensive security setup can be challenging.
This post provides a clear, step-by-step guide to configuring Salesforce security in a structured manner.
Before you begin
|
Salesforce Security Concepts
The table below provides an overview of key Salesforce concepts related to security configuration:
| Item | Description |
|---|---|
| Object | An object type stored in Salesforce such as an account, order, etc., including custom, user-defined objects. An object roughly corresponds to a table in a relational database. |
| Record | An instance of an object, actual record in the database (e.g., ACME Corp. account). A record corresponds to a table row in a relational database. |
| Field | An individual field on an object or record (a column in a relational database). |
| Record Type | Optional, special field type determining sub-type of an object. For example, a case object might be a Customer case or an Internal case, each one having slightly different characteristics. Record types drive:
More information about record types is available here. |
| Page Layout | Page layouts define how an object is presented to a user (which fields are visible, their order, available action buttons, etc.). An object might have multiple layouts, e.g., support team may see different account details than the sales team. Another example would be a custom ‘Network Element’ object that could have a router, switch and firewall type and display different fields for each type. Page layouts are assigned on a per record type/profile basis (a two-dimensional matrix):
More information about page layouts is available here. |
| Profile | Profiles define how users access objects and data, and what they can do within a Salesforce org. Each user can have only one profile. More information about profiles is available here. |
| Permission Set | A set of permissions (usually supplementing profiles). Unlike profiles, user can have multiple permission sets. |
| Permission Set Group | A collection of permission sets, so they can be assigned to users in bulk. |
| Role | A role describes user position in the organization hierarchy (CEO, VP Sales, VP Delivery) and is used in conjunction with Sharing Rules (see below), determining which records (not objects!) can be accessed by a user. Each user can only have one role. More information about roles is available here. |
| Sharing Rule | Sharing rules define how records are ‘shared’ based on role in the organization and reporting structure. By default, users can see their own records, but sharing rules enable exceptions, e.g., a manager can see his employees’ cases, opportunities, etc. More information about sharing rules is available here. |
| Lightning Experience | Salesforce Lightning is a modern user interface with mobile client support (as opposed to the former Classic interface). Lightning also adds additional functionality such as Lightning Pages and Lightning Apps (described below) that have impact on security configuration. More information about Lightning Experience is available here. |
| Lightning Page | Lightning Pages extend Page Layouts for the Lightning user interface. They adapt to target device and are built out of components (Page Layout is one of them) and are highly customizable. Object Lightning pages are assigned on a per-record type/profile/Lighting App basis (a three-dimensional matrix):
More information about Lightning Pages is available here. |
| Lightning App | A Lightning App (“app”) is a collection of menu items and a home page. It usually groups items required to perform a well-defined business function (e.g., “Sales”). Apps do not affect access to records, only what is presented to users. Third party packages usually provide their own apps, but they can be built as needed. It is a common practice to build an app on a per-department basis. Apps are accessible via the Salesforce app launcher:
More information about Lightning Apps is available here. |
| Lightning App Home Page | Each app has its own home page. Home pages are Lightning pages and can be designed using any components such as list views, dashboards or even completely custom ones. Home pages are a great place for user work items such as active tasks, open orders, open cases, etc. |
Salesforce Security Model
Salesforce has a two-layer security model (we recommend reading this blog for details):
- Object and Field-Level Security: This first layer controls which objects and fields can be accessed by users (e.g., a user has access to opportunities but not to support cases).
- Record-Level Security: The second layer determines which individual records can be accessed by a user, e.g., a sales rep can only access his opportunities, a manager can access opportunities for his entire team.
Applying Security Model to Organization Chart
An organization’s structure usually maps directly to Salesforce’s Object and Record-level security:
- Departmental structure determines what can be seen and how it is presented to the users. In Salesforce, this corresponds to:
- Access to objects and fields → Managed through Profiles and Permission Sets,
- How data is displayed → Managed through Page Layouts and Lighting Pages.
- Employee hierarchy/reporting structure determines access to individual records controlled by Roles and Sharing Rules.
A Step-by-Step Approach to Salesforce Security
| Step 1 | Profiles |
Profiles are the starting point for security configuration:
- Isolate and leave Sales profiles intact (most likely your Salesforce was initially used for sales, and these are already configured and working).
- Create additional profiles according to the following rules:
- Create profiles per department or team,
- Share profiles if possible, to minimize their number,
- Generalize as much as possible, e.g., if a Finance department consists of Accounts Payable (1 employee), Accounts Receivable (2 employees) and Accounting (2 employees), creating a single Finance profile makes most sense.
- Review custom/standard object access on each profile. Keep profiles simple, and handle as much configuration as possible via permission sets and permission set groups.
| Pro Tip | It is unnecessary to create separate profiles for managers — a basic profile and a manager permission set or set group and sharing rules are usually sufficient. |
Unlike permission sets and set groups, profiles cannot be deployed as part of Salesforce packages or change sets.
| Step 2 | Permission Sets and Groups |
Permission sets supplement profiles. We recommend the following approach to configuring permission sets:
- Identify the exceptions — typically these are Delete operations or items that raised suspicions during profiles configuration (Definitely not everybody should be able to do that!). Create separate permission sets for these.
- When dealing with a large number of permission sets, combining them into permission set groups for departments or teams works best.
| Pro Tip | Permission sets are a limited resource and should be used with caution (Setup → Company Information → Permission Set Licenses). |
| Step 3 | Roles and Sharing Rules |
- Configure roles — they will typically reflect the reporting structure of the organization chart, so this part is usually relatively easy.
- For each object review its sharing rules. This will depend on business needs; however, it is generally a good policy to start with restrictive sharing rules and opening them gradually.
| Pro Tip | Sometimes it is difficult to determine sharing rules for non-sales objects, such as cases, orders, etc. In that case one may start with a high-level ‘delivery’ or ‘support’ roles and refine them later on. |
| Step 4 | Page Layouts and Lighting Record Pages |
Most objects that have record types will have a per record type layout. This is a good starting point; additional, profile specific layouts can be added on an as-needed basis.
The same applies to Lightning record pages.
| Pro Tip | Maintenance of multiple layouts gets cumbersome, so new non-record type layouts should be added with caution. |
| Step 5 | Lighting apps and Home Pages |
Since every profile has only one default app, it is best to define an app and home page for each.
| Step 6 | Groups |
Groups are important for visibility and sharing of list views, dashboards and reports.
Unlike profiles, groups may be very granular as particular departments and sub-departments may have list views/reports specific to their activities.
| Step 7 | Queues |
Queues are needed for group object assignments, e.g., a task is assigned to a departmental queue, before assignment to an individual.
Typically queues configuration closely mirrors groups configuration.
Naming Conventions
For businesses with complex organizational structures and permission systems, it is a good practice to establish a naming convention for security objects. This makes security easy to configure, maintain and understand.
For example, a fictional ACME Corp. may use the following convention:
- Profiles: ACME Sales, ACME Orders, ACME Customer Service, … — following departmental names,
- Permission Set Groups: ACME Sales, ACME Sales Managers, … — following departmental names with separate permission sets for regular users and managers,
- Permission Sets: AC Contact Management, AC Order Management, … — following areas of operation.
A configuration based on these conventions may look like this:
Conclusions
In today’s business landscape, cyber and data security are top priorities. While Salesforce’s security model can be complex — especially when used beyond basic CRM — configuring it in a structured way ensures both effectiveness and ease of maintenance, even as your organization evolves.
Contact us today to find out how we can help you!
