Configuring Salesforce security – a step-by-step process
Salesforce security can be quite intimidating. It is a complex system with a lot of moving parts, which is the price for its ability to handle virtually any data access / sharing scenario.
When using Salesforce only for CRM, out-of-the box configuration is usually sufficient along with minimum changes to roles hierarchy. Due to involved complexity, figuring out a practical, comprehensive approach to Salesforce security configuration can be difficult.
This post outlines a step-by-step process to Salesforce security configuration.
Before you begin
|
Salesforce security concepts
The table below summarizes 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 structure 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 this blog for details):
- The first layer (the object layer) determines which objects & fields can be accessed by users (e.g., a user has access to opportunities but not to support cases).
- The second layer (the record layer) determines which records can be accessed, e.g., a sales rep can only access his opportunities, a manager can access opportunities for his entire team.
Security model applied to organization chart
Organization charts typically translate directly into Object and Record layer access:
- Departmental structure determines what can be seen and how it is presented, so in Salesforce terms corresponds to:
- Access to objects and fields → Profiles and Permission Sets,
- Their presentation → Page Layouts and Lighting Pages.
- Employee hierarchy/reporting structure drives access to individual records → 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 & 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
Salesforce security is pretty complex, and its configuration may be challenging, especially if Salesforce is used for more than just basic CRM.
Nextian is a vendor of Quote-to-Cash (QTC) software for cloud and communications helping providers accelerate growth and increase customer lifetime value.
Contact us today to find out how we can help you!
