VitePress

Appearance

Exercise 3: Dive into User Security ​

In this exercise, you'll use User Access Summaries, reports, and Health Check to identify over-permissioned users and enforce the Principle of Least Privilege.

Scenario ​

We've all been there: a user hits a Permission Denied error, and suddenly it's an admin emergency. To avoid an influx of support tickets, a former admin gave every user View All and Modify All access. While the team is working unhindered, the org is violating the Principle of Least Privilege. Let's reel in that over-shared access and make sure users have exactly what they need to do their jobs — and absolutely nothing more.

The Principle of Least Privilege says users should only have the permissions they need to do their job, and nothing else. As admins, we often deal with permission creep — scenarios where users have been granted increasingly broad access, often well beyond what their role requires. Full access reduces roadblocks but creates significant security and data concerns.

Step 1: Troubleshoot with User Access Summaries ​

When working with a user, you notice he has more access than he needs to do his job. Let's take a look at James's access through the View Summary feature on his User Record:

  1. Click and open Setup.

  2. Type Users into the Quick Find.

  3. Click Users.

  4. Select James Doe.

  5. Click the View Summary button.

  6. On the User Access Summary, select the Object Permissions tab.

    Here you can see that with the System Administrator profile, James Doe has the ability to Read, Create, Edit, Delete, View All Records, and Modify All Records for all objects.

As a System Administrator, it makes sense for your profile to have this much access. However, some users have been made System Administrators for convenience — not need — and that violates the Principle of Least Privilege. Let's identify these over-permissioned users and update their settings.

Step 2: Use Reports to Define Problem Users ​

In some orgs you may have hundreds of users, so the easiest way to check for potentially problematic users is to run a report. Here, we're looking for active users with a System Administrator profile who possibly don't need to be.

  1. Open the App Launcher.

  2. Type Reports into the Search bar.

  3. Click Reports.

  4. Click Public Reports.

  5. Type Active System Admin in the Search bar.

  6. Click the Active System Administrators report to open and run it.

Your report should look similar to this:

As you can see, there are 5 System Administrators even though you are the only Salesforce Administrator. This has also been flagged on your Health Check as an Informational Security Setting since the percentage of active internal users with System Administrator profile is higher than recommended.

Step 3: Remove System Administrator Profiles to Enforce Least Privilege ​

  1. Go back to Health Check and scroll down to Informational Security Settings.

  2. Click Edit next to Percentage of active internal users with System Administrator profile.

  3. Click Edit next to user James Doe (Regional Sales).

  4. Select Profile and change the value from System Administrator to Standard User.

Apply a permission set-led security model that is scalable. Profiles set the minimum access for your users. For maximum restriction, use the Minimum Access - Salesforce profile as a baseline, then layer additional access using Permission Sets and Permission Set Groups.

Summary ​

You used User Access Summaries, Reports, and Health Check to uncover and update user settings to enforce the Principle of Least Privilege. If you were to continue beyond this workshop, your next steps would be to move to a permission set-led model — shifting from profiles defining access to permission sets layering access. This builds a system that's easier to maintain, easier to audit, and easier to adapt as your org grows.