How to build a permission model in Salesforce?

Common challenges with respect to permissions

What challenges should you be prepared for? How do we at Craftware usually handle them? Below, you can find several examples.

1. Handling fill-ins

Sometimes when an employee responsible for a specific area of sales or customer service is absent from work, the person who covers for them wants to have quick and easy access to the customer base of their absent colleague. Changing contact owners may, however, lead to changes in processes. A solution here can be either a feature that allows you to automatically assign territories (one territory per a sales person) or the Account Teams feature.

2. Restricting file visibility for specific users

The default file visibility option set to „every user that has access to the record” starts causing problems when it comes to, for example, files with client deal offers containing sensitive financial data. A solution here is a feature that automatically switches the File Sharing option to Private for a specific category of files. But please note that it will make the files visible to their owner only (your corporate hierarchy doesn’t really work here!).

3. Reporting on all accounts for Partner Community users

Theoretically, enabling full account visibility for Salesforce Community users provides you with vast reporting capabilities. In reality, however, for the sake of security, Salesforce doesn’t allow External users to generate reports if the currently selected visibility option is other than Private. This can be solved by setting your view to Private (with Sharing Rules).

4. Setting visibility for line managers

At some companies, the role hierarchy not always reflects the actual hierarchy of line managers. For example, when you work in a project team, your supervisor in the hierarchy is the project manager. However, such things as leaves of absence or remuneration are handled by the line manager who does not supervise the project itself. How can you solve the problem of accessing holiday requests or salaries? A way to deal with this is to make use of the Manager Groups feature, and then set permissions to access records through Manual/Apex Sharing.

5.  Setting record visibility based on the status, etc.

Sometimes, we don’t want users to see our clients’ sensitive data if they do not directly deal with those clients. At the same time, we want our users to have access to public information regarding clients such as tax idenitification numbers or addresses. To solve this problem you can duplicate records, and display their public versions only.

What advice should you give to your client?

Although your satisfaction of creating advanced solutions is important, solutions are meant, first and foremost, to satisfy your client and the users. The bottom line is: the solution has to work, be user-friendly, and be easy to maintain. So, what is of high importance here is listening to your client, understanding their needs, and presenting your client with the best option. Sometimes, it means that you have to explain to your client that their own idea of how to solve a specific problem will not necessarily work in reality. That’s why, it’s important to make your client aware of the fact that if you disagree with them, you’re doing so only because you care about the final outcome and the comfort of use of the solution.

What solutions should you discourage your clients from using? These are a few examples.

• Narrowing the view. For example: „I want to see the status of other users’ tickets only.”

A requirement that is hard to meet (as an example, please see the solution no. 5 in the previous paragraph) and is completely unscalable in the case of big organizations. Salesforce doesn’t provide us with a ready-made solution here.

• Limiting the possibility to enter information depending on a  life cycle stage, for example: „I want to enter specific data only at the moment of creating a client’s account.”

Well, it can be done, there is a way – after all, we have validation rules. But what will suffer here is UX.

• Changing the activity model, for example: „All the activities are controlled by record access unless…”

Such an approach causes difficulties when it comes to integrating Lightning Sync and Lightning for Outlook.

• Visibility of different fields depending on the status, for example: „I want to see different fields depending on the current stage.”

The best answer here is Sales Path. However, problems start to arise when you need to display more than 5 fields in a status.

• Extending sharing options, for example: „I want to expand Account/Opportunity Teams by giving them access to custom related objects.”

This is no longer a problem. Until not so long ago, it was impossible to extend permissions based on Account/Opportunity Members, because it was not possible to use them for automation. However, it became a reality last month ?

How to approach permissions design?

How to tackle permissions design? How to build a model that won’t surprise you with anything? What works well here is going from the whole to the part.

First of all, as a Salesforce developer or consultant, make sure that you know what the technical possibilities are regarding data access control on different levels (meaning CRUD and FLS). Having that knowledge (that is, the basis), you can efficiently manage permissions in a given project.

When you are about to begin, set basic CRUDs for different business groups, and determine a role hierarchy. This will make clear from the start what elements your client uses, and more specifically, who will be working with what. Additionally, determine the needs related to Organization Wide Defaults, but remember from the very beginning that if permissions are too broad, you won’t be able to limit them later on.

How to do it properly? By enquiry, deduction, and natural suspicion, you need to find persons with the least permissions, and build OWD based on them.  Only then can you extend permissions with the use of Sharing Rules and Record Types.

Be careful when designing Record Level Security for such standard objects as Activity, Files, or Approvals!

What is incredibly important — Salesforce never stops evolving, so you need to stay up-to-date with all the changes. Trailheads, especially the ones containing information about the upcoming releases, provide you with a plethora of useful information regarding new solutions, and they are presented to you in a very accessible manner.

And finally, the most important rule that I’ve mentioned before: listen to your client, don’t put your comfort above theirs, and ask them questions. Ask questions yourself, too! I’m not kidding! Watch out for keywords. What are they? You’ll find out with time 🙂