You’ve likely heard us talk about the importance of the principle of least privilege (PLP) by now, but if you’re still not familiar, let me break it down for you. The PoLP is a cornerstone of modern cybersecurity. Essentially, the principle states that users should have the minimum access needed to do their jobs, and no additional privileges. Following this principle correctly helps reduce the likelihood of a security breach due to overprivileged accounts, minimizing the risk of things like mistaken (or intentional) data leaks or tampering, or manual errors that could disrupt business.
Here are three ways you can streamline user security and fortify your Salesforce org with the PoLP.
What’s great about the PoLP is that it can also be applied to any platform, including Salesforce! As admins, you can apply the PoLP to your Salesforce org in several ways. The most common use case is to configure permission sets to grant minimal access to users; we know how easy it is to unintentionally over-grant permissions or inherit users that are over-privileged.
If you’re curious about the current state of your users, you can conduct a privilege audit by reviewing all existing accounts and permissions to ensure there are no over-privileged accounts. Moving forward, you’ll also always want to assign Salesforce’s least privilege profile (the Minimum Access user profile) to users, and layer on permissions using permission sets and permission set groups according to the access required. You can find more details about how to do this in the Protecting Data with the Principle of Least Privilege blog post, and try using permission set groups to make the process more scalable.
Another use case where you can apply the PoLP is by adding visibility rules to dynamic pages. Since the concept of the PoLP dictates minimum access—which, in addition to the ability to make changes to fields and objects, also includes visibility—it can be applied to which types of users can see a field. For example, you can have a field or set of fields hidden until a person with a certain profile or permission visits the page by setting visibility filters on Field and Field Section components. You can also show a field only when another field is set to a specified value. By making certain things accessible only to specific users with specific permissions, you’re actually following the PoLP!
Another very important application of the PoLP is quickly deactivating users who have left your organization or changed roles. Once a user no longer requires access to certain data, or to Salesforce as a whole, you should remove their access as soon as possible. We’ve all heard about (or experienced) issues with salespeople downloading customer and prospect data after leaving the company—you can help prevent that by following the PoLP!
Remember, the data stored in your Salesforce org is precious and you should protect it in everything you do. It’s always recommended to think critically and limit access within the platform whenever possible, which in turn will help increase the security of your Salesforce instance.
As admins, you hold the keys to success for your users and companies to get the most out of Salesforce. You have the unique opportunity to build and manage trusted solutions that drive productivity and innovation through five core admin responsibilities: security, user management, data management, analytics, and a new core responsibility: product management. The […]
Winter ’25 is almost here! Learn more about user management and check out Be Release Ready to discover more resources to help you prepare for Winter ’25. We’re continuing to innovate in Setup starting with user access and user management. We have several exciting enhancements in store for Winter ’25–many thanks to your feedback and […]
Awesome Admins, we know that troubleshooting user access is a common task. You’re frequently asked questions like “Why can Jane access this field, but John can’t?” or “Why can John view this record when he shouldn’t be able to?” In Summer ’24, we introduced helpful summary views for users, public groups, permission sets, and permission […]
