How to Manage User Requests for Salesforce Admin Permissions

Once upon a time, an End User came to their Salesforce Admin asking for the Modify All Data permission. The Admin knew this wasn’t a good idea, but how to best explain it to the end user? How can the Admin find out what the real need is?

I like to use analogies to help get people out of the moment of the request. Many times, they’re trying to meet a specific need that can be solved in a different way, but they’ve gone straight to their proposed solution. Giving them an analogy helps change the conversation to find the specific need.

Imagine you live in an apartment building (or a condo, or a dormitory). There is a floor of apartments above and below yours. You have a tiny kitchen next to a nice sized dining room. It’d be great if you could just remove that wall to make more space. You’re going to go get a sledgehammer and start knocking that wall down, right?

Of course not! A number of things could go wrong if you start knocking down walls, especially in an apartment building. You need to go to the Supervisor and talk with them. The Supervisor would likely have an Engineer look at the blueprints of the building to make sure removing that wall isn’t going to cause the floor above you to come crashing down. The Engineer would also look to see if there is anything else important in that wall that has to stay in place or needs to be moved: plumbing, electrical, or venting. The Supervisor would also have to work with the local Permit Officer for any permits required to change the structure of the building. Once all of those things are done, the Supervisor may come back and say they can’t remove the wall, but they could put in a wider door for you.

Now let’s go back to our end user’s request. Think of the user’s request to have Modify All Data as the desire to remove the wall in the apartment. However, if the user can modify any data they can access, they could unknowingly make updates that cause field update automations to run, updates to other systems to process, emails to send to internal users or customers, changes in forecasts to be made, reassignments of records to new owners, and more. They would also have more records showing in their views and reports that have to be filtered, more fields displaying on those records that they may not understand or clutter up their layouts, and more.

There are a few strategies that the Admin can leverage. Many times, a company will have rules such that the powerful permissions like Modify All Data are not granted to end users, only the Admin or integration users. But what is an Admin to do when the end user won’t accept that answer?

First, use the analogy above to change the conversation and focus on finding out what the need is that the end user really is trying to solve. Many times it turns out there is some specific data that they need to view and update for their team. The key is to identify what the specific need is, not what the end user thinks the solution should be.

The Admin can now make a list of options that meet the specific need identified with the end user. Instead of Modify All Data, perhaps they need a different role in the role hierarchy to view and edit Cases owned by their team. Or perhaps they need a permission set with Modify All for a custom object that is only used by their department. Or perhaps an adjustment is needed in the Territory Hierarchy so the end user can edit forecasts for a team. The list goes on.

The Admin then takes the specific need and the list of options to the Developer or Architect (the Engineer in our apartment example) to understand the impacts to not only the Salesforce org, but any other integrated systems and business processes. This will likely remove some of the options from the Admin’s initial list and add some new options. The Admin can now make a recommendation from the updated list of options.

The Admin finally would take the recommended option to the Change Control Board (the Permit Officer in our apartment example) for review and approval.

The end goal is to change the conversation from a solution to identifying the problem. Now you can handle any End User’s request for those touchy Admin permissions.

This blog is part of our larger “Ask an Architect” content series. To learn more about engaging a Salesforce.org Customer Success Architect in your organization, please contact your Account Executive.

About the Author
Marie van Roekel is a Principal Customer Success Architect at Salesforce.org, based outside of Atlanta, GA. As part of the Advisory team, she works primarily with nonprofit customers to ensure they are successful in their implementations of Salesforce technologies and best practices, enabling them to better achieve their missions.