Solo Admins, especially in larger organizations, have bandwidth issues. Being pulled in multiple directions, engaged in meeting after meeting and no time to manage users and the basic configuration of Salesforce. It becomes frustrating and difficult to manage all of this.
Depending on your org and the structure of the team, assigning Delegated Administrators may be a great way to off-load some of that lower-level work. However, caution should be used when assigning Delegated Administrator permissions in Salesforce.
Defining a Delegated Administrator
Delegated Administrator’s are users who are given admin-level permissions. The idea to give trusted individuals access to Salesforce to help with the following:
- Create and edit users including password resets, teams and groups.
- Assign users to roles and permission sets
- Unlock/Freeze Users
- Login as a user who has granted login access (now on by default for Summer ’15)
- Manage custom objects (i.e.: field labels, values etc.)
The use case that Salesforce uses is as follows:
Let’s say you want the Customer Support team manager to manage users in the Support Manager role and all subordinate roles. Creating a delegated administrator for this purpose allows the System Administrator to focus on other administration.
Basically, providing Delegated Admin rights allows you, the System Administrator, to focus your time and efforts on other administrative tasks, freeing up bandwidth.
This sounds glorious! And the permissions required to become a Delegated Admin are pretty minimal: Customize Application and View Setup and Configuration.
But those permissions are more powerful than they appear.
Caution: Excessive Permissions Ahead
On the surface, the Customize Application permission seems harmless, but it opens up a whole lot of permissions that you may want to keep restricted to only System Administrators. The Customize Application permission, when activated, will automatically enable the following permissions:
- Customize the organization using App Setup menu options.
- Edit messages and custom links.
- Modify standard picklist values.
- Create, edit and delete custom fields.
- Create, edit and delete custom fields.
- Create, edit and delete page layouts (also requires the “Edit” permission for the record).
- Set field-level security.
- Create, edit and delete custom links.
- Edit the Lead settings.
- Activate big deal alerts.
- Create record types.
- Set up Web to Case and email response rules.
- Set up Web to Lead and email response rules.
- Set up assignment and escalation rules.
- Set up business hours.
- Set up Email to Case or On-Demand Email-to-Case.
- Edit Self-Service page layouts and portal color theme.
- Set up and enable multilingual solutions.
- Setup team selling.
- Set up account teams.
- Map custom lead fields.
- Manage queues.
- Create, edit and delete workflow rules, tasks, field updates, outbound messages and alerts.
- Create, edit and delete custom s-controls, custom objects, and custom tabs.
- Rename tabs.
- Manage custom apps and Service Cloud console apps.
- Create and edit public calendars and resources.
- Set up the console.
- Enable, setup and modify the Salesforce Customer Portal.
- Set up and schedule analytic snapshots to run.
- Create communities for Ideas and Answers.
- Create Visualforce email templates.
That is a whole host of permissions that a standard user is awarded. This is about the time that some one says “with great power comes great responsibility” but I don’t fully agree. These powers, when given to a non-educated user, can be detrimental to the organization.
So, what is an Admin to do? All hope is not lost.
What Permissions Do You Really Need?
Before activating these two “simple” permissions, it’s important to fully understand what the Delegated Admins in your system will need to accomplish. What will their role be and how do you want them to interact with Salesforce and your companies data?
The best way to get started is to make a list of the tasks that you, the System Administrator, wish to off-load to someone (or a group of people).
Given those tasks, review what individual permissions are needed to perform those tasks. Once those permissions are documented, you’ll need to make a decision, based on the level of access granted, if you are willing to entrust those individuals with that level of access.
Let me be clear on this point. You shouldn’t NOT entrust someone with this level of access to Salesforce. If the impact to your job is significant, and the individual is someone you and the business trusts, this is a good thing. The key is to understand exactly what they will have access to. This is what we call doing your due-diligence.
With this work completed, you may be able to evaluate the required permissions and determine that a Permission Set is much more palatable and appropriate for your companies organization. This is what I’ve done in the past and it has worked well; meeting the needs of the organization while maintaining a level of access needed to complete the tasks required and no more.
Finding Users You Trust
Finding the right user is an important part of this process. You’ll be entrusting this user with a heavy amount of admin-level permissions. Care should be taken when selecting the individuals for this role.
Create a job description, which will outline the duties and characteristics of a Delegated Administrator. Not only will this written document help in keeping focus on the appropriate individual during the selection process, but it can be provided to the Delegated Administrator to help them understand their role and duties as a Delegated Administrator.
Here are some characteristics to think about when selecting a person for this role:
Trustworthy – the individuals should have a positive reputation in the organization. They should be someone that you would share private information with and no afraid that it will pass through their lips until told it’s okay to speak.
Customer Service Minded – they should have the heart of a teacher. Patience is something they have an abundance of. They will be working directly with other end-users and should have the ability to politely troubleshoot and respond to user inquires. They are an extension and representation of you. Choose wisely.
Excellent Communicator – interpersonal and general communication skills should be evaluated. The Delegated Administrators should be clear and concise in their speech, both written and verbal.
Accessible – because the Delegated Administrator will be a representation and extension of you, the System Administrator, they need to be accessible to users. While this role may be an “add-on” to their every-day position, they should still be available via telephone, instant message or phone during business hours.
Once one or multiple users have been selected, be sure to communicate the new role with them, and ensure they are willing to help.
Note that you’ll also want to think about how this fits into your overall support model. Several years ago I wrote about how to structure your support model. You can read the post here.
Are you using Delegated Administrators in your org? What best practices can you share? How has it helped you focus on more strategic tasks versus the day-to-day? Leave a comment below!
5 thoughts on “ Become More Efficient With Delegated Administrators ”
I’m not sure I understand delegating vs giving a user system administrator profile. I’m the main administrator at DG, but I need someone to back me up, especially when I’m out of the office on PTO. I’ve given 2 others who have had training the system administrator profile.
Hi Linda. The term “Delegated” just means that you’ve identified someone to provide “admin-level” access to in an attempt to offset or in your case, backup the administrator. To me, there isn’t much of a difference. The key is to understand what you want these individuals to do and have access to and then determine if you want to provide all of the permissions listed or some of the permissions. This is based on how you and your company want to setup delegated admins. I tend to use permission sets and provide access to the fewest number of system permissions possible.
Brent, we have delegated admin set up in our org with the ability to login as other users and manage users BUT they do not have the customize application permissions. I just tried it by logging in as the actual user assigned to delegated admin and they can’t do any of the customize application actions.
To manage delegated administration (Which would usually be a system admin to manage who is a delegated admin/which profiles/permission sets/roles/objects can be managed by a delegated admin, you need “Customize application” permissions. However, to be a delegated administrator, you need “View Setup and Configuration” permissions. We’re highly regulated industry so there is no way we would have granted delegated administration to users who can then configure the app in Production.
Jennifer, you are totally right! I wrote about the wrong set of permissions in the post. It looks like I have some updating to do! Thanks for pointing that out. However, that being said, it is still important to select your users carefully and determine the minimum number of permissions to award a user based on company (or industry in your case).