How to Gather Security Requirements in Salesforce

Collecting security requirements can seem like an uncomfortable challenge. As an administrator/consultant, it is unrealistic to assume that end users grasp the various security nuances in Salesforce, such as roles, profiles, permission sets, permission set groups, muting, sharing sets, implicit sharing, and the distinction between manual and programmatic sharing. 

Therefore, the following question arises: how can you effectively gather requirements and straightforwardly articulate them and enable users to communicate who sees what in Salesforce precisely? In this article, I explore various scenarios aimed at strategically incorporating security measures into your system. The goal is to guarantee the optimal formulation of requirements for the development of a robust security model.

Gathering Security Requirements With Business Users

When engaging in the process of gathering security requirements with business users, regardless of your role as an administrator, business analyst, or consultant, it’s essential to approach the interaction under the assumption that business users may not be familiar with the distinctions between roles and profiles/permission sets in Salesforce. 

To facilitate a more effective requirements-gathering session, it is advisable to come prepared with a set of targeted questions, ensuring a smoother and more productive dialogue. In the scenario that you are discussing the Account object, ask your business user the following questions:

Question to the business user: Which personas should be able to see Accounts? 

Answer from business user: At a minimum, everyone should be able to see all Accounts. 

What this means for you: Great – you now know what it means in terms of Organization-Wide Defaults (OWD). It means Public Read Only on Accounts. All the personas must have a minimum Read on Account object. As a consultant, you must know that just making the OWD Public Read Only does not grant users Read on Account if they don’t have the permission, either through their profile or permission sets (you should now be using permission sets more because of the eventual retirement of profiles), to Read Accounts. 

Follow-up question to the business user: Now that you said all users should be able to see Accounts, which specific users should be able to edit and delete Accounts that they own? Explain the concept of Ownership of records. Ownership of records can be done by creating the record or transferring because of a business process like someone leaving the organization or more advanced concepts like Enterprise Territory Management. 

Answer from business user: We want our Sales reps Account to edit their own Accounts. Usually, they are the ones that must own the Account. We do have exceptions to the rule that only sales reps must edit their accounts as we want our finance teams to edit all Accounts irrespective of ownership. 

After all, they will enter credit limit and if we must hold on doing any further business with the account if they are overdue on their payments. We also want Sales Managers, who sales reps report to, to edit their own reps Accounts. 

What this means for you: From the above set of requirements, you understand that:

1. Sales reps must be able to read and edit their Accounts. 
2. Sales managers must be on top of sales reps in the role hierarchy. From object-level permissions, they also must have read and edit permissions on Accounts. 
3. Sales reps and sales managers can share the same set of object-level permissions (profiles or permission sets), but sales managers must be higher on the role hierarchy so they can edit sales rep’s Accounts. It may be too early to determine if sales reps and sales managers can share the same permissions (profiles or permission sets), but if you determine through a round of questioning that sales reps and sales managers have all the same object-level permissions, then role hierarchy is the key. Recognize the patterns and capabilities of personas to design your security model. 

Follow-up question to the business user: Regarding the exceptions for finance users, the business user suggested that finance teams must be able to edit all Accounts. But, they alluded to specific attributes such as credit limit and Account hold. So your follow-up question should be: should they be able to edit other attributes on the Account such as billing address, shipping address, and any other attributes?

Answer from business user: Finance users should be able to edit credit limit, Account hold, billing address, and billing contact fields on all Accounts. But they should not edit anything else. 

What this means for you: From the above set of requirements, you gather that:

1. Finance users must have access to all Accounts. You can solve this by putting them on top of the role hierarchy or creating a sharing rule. 
2. Finance users must have read and edit object-level permissions provisioned either with profiles or permission sets. 
3. Not all attributes should be editable by finance users. This tells you this is field-level security detail. Remember to detail this in your user story so that the field-level security is outlined correctly. 

Question to business user: Knowing their business, you want to find out if there are any nuances to record access between sales managers in the US and Canada. You want to know if these managers must be able to edit each other’s Accounts. If they own any Accounts should they be able to edit their sales rep’s Accounts? 

Answer from business user: Only the US managers are allowed to edit their own accounts and the sales reps’ accounts under them. They must be able to also edit any Accounts owned by the Canadian sales manager as well as the sales reps under the Canadian sales manager. However, the Canadian manager should only be able to see all Accounts and be able to edit only Accounts owned by them and their team. 

What this means for you:

1. There needs to be a role hierarchy that is separate for the US and Canada.
2. There needs to be a sharing rule so that the US manager can edit Accounts owned by the Canadian sales manager and his subordinates. 

Question to business user: Are there any exceptions or any hidden or unmentioned business processes that you must be aware of? 

Answer from business user: When an Account is on hold because of overdue payments, then a disputes manager must be able to edit certain attributes on the Account in case of resolution or add additional notes about collections. 

What this means for you: 

1. This persona’s role can be a branch on its own until you determine through a round of questioning. This persona only needs to edit Accounts when an Account is on hold. This means that there should be a criteria-based sharing rule based on the Account hold attribute.
2. Again, this persona must have read and edit on Account as well, as this defines the base-level permission. The sharing rule only provisions edit on accounts that they do not own. 

By being non-technical with the business user, we were able to solicit requirements that spanned a lot of security concepts in Salesforce, such as profiles and permission sets, roles and hierarchy, role-based sharing rules, criteria-based sharing rules, and field-level security. This is intended to get the conversation going about how you can separate technical terms when conversing with your business users. 

How the Above Scenarios Translate to User Stories

1. As a system user, I would like the ability to easily access and view all accounts. This will enable me to stay informed about our current customers, prospects, past customers, competitors, and vendors, fostering a more seamless understanding of our business relationships.
2. As a sales rep, I need the ability to view all accounts and edit accounts that I own so that I can keep my accounts up-to-date. 
3. As a sales manager, I need the ability to view all accounts and edit accounts that I own whilst editing accounts that are owned by the sales reps I manage so that I can keep my accounts and my team’s accounts up to date.
4. As a sales manager managing US-based accounts, I need the ability to view all accounts and edit accounts owned by Canadian sales managers and their team’s accounts so that I can make any necessary updates on our Canadian business. 
5. As a finance user, I need the ability to read and modify all accounts, regardless of ownership, while only selectively editing specific attributes on the account. This means I can efficiently update and manage essential financial information associated with each account. 
6. As a disputes manager, I need the ability to view and edit all accounts, irrespective of who owns the accounts. I will also selectively edit specific attributes on the account, only when an account is on hold for payment-related issues.

Final Thoughts

Don’t expect your business users to tell you exactly how the security should be designed in Salesforce. At the same time, don’t expect that you will get the model correct on your first attempt. A few times you might realize that you are creating the exact same persona (profile/permission set group) twice with the only difference being that one persona needs to edit records they don’t own. This means that this persona is a role that sits on top of the other persona in the form of the role hierarchy.

Don’t expect your business users to understand all the concepts such as roles, profiles, permission sets, etc. These are your concepts and you must break these concepts down into plain language so that the business users don’t feel overwhelmed when trying to understand Salesforce terminology. 

You must know your fundamentals thoroughly so that you can have a good discussion to capture great requirements. Yes, things change with every release in Salesforce, but security fundamentals have not changed so drastically. Permission sets are slowly replacing profiles, but this is more of a lateral shift than a drastic change. There are restriction rules now that make the sharing model more interesting and more complex despite the fundamentals being the same. The more thorough you are in your fundamentals, the more comfortable you will be discussing these concepts in non-technical terms.