User Access Policies: a new way to manage permissions

Cet article est également disponible en français

When your organization has a large number of users, one of the challenges that every company faces is ensuring that they have the right level of data visibility and appropriate permissions.

Nowadays, profiles are becoming less commonly used to manage user permissions, as there are other mechanisms available to determine what actions users can perform and what resources they can access. This is also recommended by Salesforce. Some of these mechanisms for managing permissions and visibility include Permission Sets, Public Groups, and Queues.

Different Approaches with a Common Goal

I have seen various approaches to managing user creation and permissions, ranging from more sophisticated methods to more manual ones:

• Centralized management at the enterprise level, using identity federation systems that map Active Directory groups to corresponding permissions.
• Batch, Trigger, or Flow-based approaches that consider user characteristics.
• Manual approaches (yes, they still exist!) using Excel spreadsheets listing different permissions.

However, regardless of the approach used, a perennial question will arise: “Why can’t this user see a particular record?” Even worse, there are cases where users can see records they should not have access to.

This requires a thorough investigation to understand the source of the problem.

Nested Visibility Mechanisms

If you’re not sure where the problem lies, a quick reminder may be helpful.

The image above represents the interlocking mechanisms of visibility sharing: Public Groups, Queues, and there are others like Teams, for example. It is clear that simply checking the members of a group or a queue will not answer our question.

In an ideal world, we would have a feature in the setup where we could verify assignments to groups, permissions, queues, etc., and obtain a detailed view of the associated rights.

In an ideal world, we could assign or remove rights and access directly from that interface.

User Access Policies: The First Step towards Centralization

Last year, at the Dreamforce conference, I attended the Security Roadmap session where a complete revamp of visibility and permissions was announced. The promising screenshots below provide an overview of some features.

It would be possible to select a user and view all their affiliations.

Alspo compare two users and highlight the differences.

In the Summer ’23 release, a new feature is introduced that automates certain actions during user creation or modification.

Link to the official Release Notes page

The setup is pretty simple:

1. Trigger Type: Determine the trigger event.
2. Applicable User: Choose the profile to which the policy will be applied.
3. Additional User Field Filters: Add additional filters if necessary.
4. Actions: Define the actions to be applied. This can be adding:
   • Permission sets
   • Permission set groups
   • Permission set licenses
   • Managed package licenses
   • Groups
   • Queues

Does this sound familiar? Indeed, this feature follows the same logic as triggers or flows that you may have implemented.

Now, you might wonder why use this feature when the same can be achieved with triggers or flows. The answer is simple: we should always consider Low Code and standard features before considering any other mechanisms.

Conclusion

The main advantage I see is that this feature is now available declaratively. No need to rely on Apex. Moreover, it is much simpler to set up than flows. Let’s be honest, this approach is much easier to implement.

Now, does this feature revolutionize the Summer ’23 release? I would say it depends on the case. For projects where no automation related to permissions has been implemented, this provides an opportunity to start studying and implementing it.

In other cases, it might be possible to replace existing triggers with this standard approach.

In conclusion, I am thrilled to see this feature in the Summer ’23 release because it suggests that more improvements are on the way. Just like other features such as scoping rules and sharing rules details that were also on the roadmap and have since been implemented.

Exciting advancements lie ahead!