Delegated Admins in Salesforce

This is Part 12 of the Salesforce series. In earlier posts, we covered Profiles and Permission Sets to control what users can see and do, and explored record-level access through OWD, sharing rules, and role hierarchies. Now we tackle a practical question that comes up in every growing Salesforce org: how do you let someone handle day-to-day admin tasks without handing them the keys to the entire kingdom?

The answer is Delegated Administration.

What Are Delegated Admins?

A Delegated Administrator is a non-System Administrator user who has been granted a specific, limited set of administrative privileges. Salesforce provides a feature called Delegated Administration that lets the System Administrator define groups of users and assign them the ability to:

• Create and edit users in specified roles and subordinate roles
• Assign specified profiles to those users
• Log in as users who have granted login access
• Manage custom objects that have been explicitly assigned to them
• Administer users within specified roles without needing full admin access

Think of it this way: the System Administrator is the owner of the building, and a Delegated Administrator is a floor manager who has keys to certain rooms but not the master key.

How Is This Different from a System Administrator?

The key takeaway: delegated admins get a narrow, well-defined slice of administrative capability. They cannot touch org-wide configurations, automation, security settings, or anything outside their assigned scope.

Why Use Delegated Administration? Real-World Scenarios

Before jumping into setup, it helps to understand when and why this feature matters.

Scenario 1: Regional User Management

Your company has offices in North America, Europe, and Asia-Pacific. Each region has a local HR or IT coordinator who needs to:

• Create new user accounts when employees join
• Deactivate accounts when employees leave
• Reset passwords for locked-out users

Without delegated administration, every one of these requests flows to the central Salesforce admin team, creating a bottleneck. With it, each regional coordinator handles their own region’s users autonomously.

Scenario 2: Department-Level Custom Object Ownership

The Marketing team built a custom object called Campaign_Asset__c to track creative assets. The Marketing Operations Manager needs to:

• Add new custom fields as campaigns evolve
• Modify validation rules on the object
• Adjust page layouts for the marketing team

Rather than filing a ticket for every small change, the Marketing Ops Manager is set up as a delegated admin for that specific custom object.

Scenario 3: Reducing Risk in Large Orgs

Your org has 5,000 users and only two System Administrators. If one of them accidentally modifies a critical sharing rule or org-wide default, the blast radius is enormous. By distributing routine tasks (user creation, password resets) to delegated admins, the System Administrators can focus on architecture, automation, and high-impact changes — reducing the risk of accidental misconfigurations.

Scenario 4: Compliance and Audit Requirements

Some organizations have compliance requirements that mandate separation of duties. The person who configures security settings should not be the same person who creates user accounts. Delegated administration supports this pattern by allowing user management to be handled by a different group than the one managing system configuration.

What Delegated Admins CAN Do

Here is the complete list of capabilities available to a delegated administrator:

User Management (within assigned roles):

• Create and edit user records
• Reset passwords
• Unlock locked user accounts
• Assign profiles (only from the allowed list)
• Log in as a user (if that user has granted login access)

Custom Object Administration (for assigned objects):

• Create, edit, and delete custom fields
• Create, edit, and delete validation rules
• Modify page layouts
• Create, edit, and delete custom record types
• Create, edit, and delete custom buttons, links, and actions
• Define field-level security

Other:

• View setup pages related to their delegated scope
• Create public groups and manage group membership for groups that contain only users within their assigned roles

What Delegated Admins CANNOT Do

This list is equally important — possibly more so — because misunderstanding the boundaries leads to frustration.

User Management Limitations:

• Cannot create or modify users outside their assigned role hierarchy
• Cannot assign profiles that are not on the approved list
• Cannot assign permission sets
• Cannot deactivate or freeze users (they can only edit user records, but deactivation may be restricted depending on configuration)
• Cannot change a user’s role to one outside their assigned scope

Configuration Limitations:

• Cannot modify standard objects (Account, Contact, Opportunity, etc.)
• Cannot create or modify Apex classes, triggers, or test classes
• Cannot create or modify Flows, Process Builder processes, or Workflow Rules
• Cannot install or uninstall managed or unmanaged packages
• Cannot modify org-wide defaults, sharing rules, or role hierarchy structure
• Cannot create or modify profiles or permission sets
• Cannot access the Company Information page or modify org settings
• Cannot manage Login Flows, Identity Providers, or Connected Apps
• Cannot manage Sandboxes, Change Sets, or deployment settings
• Cannot modify Lightning App Builder pages (except page layouts for assigned custom objects)

The bottom line: delegated administration is designed for operational user management and limited custom object maintenance, not for system configuration or development.

How to Set Up Delegated Administration

Setting up delegated administration involves creating a Delegated Administration Group, specifying which roles and profiles the group can manage, and optionally assigning custom objects.

Prerequisites

Before you begin:

1. You must be logged in as a System Administrator (or have the “Customize Application” permission).
2. Identify the users who will serve as delegated admins.
3. Determine which roles they should manage (they will manage users in those roles and all subordinate roles).
4. Determine which profiles they should be allowed to assign.
5. If applicable, identify which custom objects they should administer.

Step 1: Navigate to Delegated Administration

1. Go to Setup.
2. In the Quick Find box, type Delegated Administration.
3. Click Delegated Administration under the Security section (the full path is Setup > Security > Delegated Administration).

You will see a list of existing delegated groups (if any). On your first visit, this list will be empty.

Step 2: Create a New Delegated Group

1. Click the New button.
2. Enter a Delegated Group Name — choose something descriptive, such as “APAC User Admins” or “Marketing Ops Admins.”
3. Click Save.

After saving, you will be taken to the Delegated Group detail page. This page has four related lists that you need to configure:

Step 3: Add Delegated Administrators

1. In the Delegated Administrators related list, click Add.
2. Search for and select the users who should be delegated admins.
3. Click Save.

These users do not need to be System Administrators. They can have any profile — Standard User, Custom Profile, etc. The delegated group grants them additional capabilities on top of their existing profile permissions.

Step 4: Define User Administration Scope (Roles)

1. In the User Administration related list, click Add.
2. Select one or more roles. The delegated admins will be able to manage users in these roles and all roles subordinate to them in the role hierarchy.
3. Optionally, check Enable Group for Login Access if you want delegated admins to be able to log in as users who have granted login access.
4. Click Save.

Important: The role you select acts as the top of a sub-tree. If you select “APAC Sales Manager,” the delegated admin can manage users in that role plus every role beneath it (APAC Sales Rep, APAC Sales Intern, etc.). Choose the highest appropriate role, but be careful not to select a role that is too broad.

Step 5: Define Assignable Profiles

1. In the Assignable Profiles related list, click Add.
2. Select the profiles that delegated admins are allowed to assign to users they create or edit.
3. Click Save.

Key point: If a delegated admin creates a new user, they can only assign one of the profiles on this list. They cannot assign the System Administrator profile (unless you explicitly add it, which you should never do). They also cannot assign any profile not on this list.

A common setup is to add profiles like:

• Standard User
• Custom Sales User
• Custom Marketing User
• Chatter Free User

Step 6: Assign Custom Objects (Optional)

1. In the Custom Object Administration related list, click Add.
2. Select the custom objects that delegated admins should be able to configure.
3. Click Save.

Once assigned, the delegated admins can:

• Add, edit, and delete custom fields on these objects
• Modify page layouts for these objects
• Create and manage validation rules on these objects
• Manage record types, buttons, links, and actions on these objects

They will see these objects appear in their Setup menu under the Object Manager.

Step 7: Verify the Setup

After completing the configuration:

1. Log in as the delegated admin (or ask them to log in).
2. Navigate to Setup. They should see a limited Setup menu.
3. Verify they can see Users under the Administration section.
4. Have them try to create a new user — confirm they can only select from the allowed profiles and can only place the user in the allowed roles.
5. If custom objects were assigned, verify they can navigate to the Object Manager, find the assigned object, and make changes.

Common Configurations

Here are some typical delegated administration setups you might encounter or implement:

Configuration 1: Regional IT Support

Use case: IT support resets passwords, creates new hires, deactivates departing employees for their region.

Configuration 2: Department Custom Object Admin

Use case: Marketing manages their own custom objects without filing tickets to the central admin team.

Configuration 3: HR User Lifecycle Manager

Use case: HR handles the onboarding and offboarding user lifecycle as part of their existing processes.

Best Practices and Gotchas

Best Practices

1. Name groups descriptively. Use names like “APAC IT Support” or “Finance Custom Object Admins” rather than “Delegated Group 1.” Six months from now, you (or your successor) will thank yourself.

2. Keep the assignable profiles list minimal. Only include profiles that the delegated admin has a legitimate reason to assign. Never include the System Administrator profile.

3. Scope roles tightly. Select the narrowest role that covers the users the delegated admin needs to manage. Selecting a role too high in the hierarchy gives broader access than intended.

4. Document your delegated groups. Maintain a simple document or spreadsheet that lists each delegated group, its members, its scope, and the business justification. This is invaluable during audits and org reviews.

5. Review delegated groups quarterly. People change roles, leave the company, or no longer need delegated access. A quarterly review keeps your setup clean.

6. Combine with permission sets where appropriate. Delegated administration handles user management and custom object admin. If you also need to grant access to specific apps or tabs, use permission sets in combination — as we covered in the Profiles and Permission Sets post.

7. Use Login Access carefully. Enabling login access for a delegated group is powerful. Only enable it when there is a clear support use case, and ensure your organization’s privacy and compliance policies allow it.

Gotchas and Common Pitfalls

1. Delegated admins cannot assign permission sets. This is one of the most common points of confusion. If a new user needs specific permission sets, the System Administrator (or an automation) must handle that assignment.

2. The “Manage Users” permission is not the same as delegated administration. Some admins try to solve this problem by giving a profile the “Manage Users” permission. This is a much broader permission that allows managing ALL users, not just those in specific roles. Delegated administration is the safer, more targeted approach.

3. Custom object changes are live immediately. When a delegated admin adds a field or changes a validation rule on a custom object, that change takes effect right away in production. There is no sandbox or staging buffer. Make sure your delegated admins understand the impact of their changes.

4. Delegated admins cannot manage other delegated admins. Only System Administrators can create, modify, or delete delegated administration groups. This prevents privilege escalation.

5. Role hierarchy changes affect scope. If the role hierarchy is restructured, the scope of a delegated group may expand or contract. After any role hierarchy change, review your delegated groups to ensure the scope is still appropriate.

6. No granular field-level control on user records. When a delegated admin can edit a user record, they can edit most fields on that record (name, email, department, etc.). You cannot restrict them to only editing certain fields on the user object through delegated administration alone.

7. Delegated admins in Lightning Experience. The delegated administration feature works in both Classic and Lightning. However, in Lightning, the Setup menu rendering may differ slightly. Delegated admins will see a filtered Setup experience, but ensure you test the user experience in whichever interface your org uses.

Section Notes

• Delegated administration is available in Professional, Enterprise, Unlimited, and Developer editions.
• You can create multiple delegated groups, and a single user can belong to more than one group. Their effective delegated privileges are the union of all groups they belong to.
• Delegated administration is a native Salesforce feature — no additional licenses or add-ons are required.
• This feature is particularly valuable in organizations that are scaling rapidly or have geographically distributed teams where centralized administration creates bottlenecks.
• For organizations with very complex delegation needs that go beyond what this feature provides (for example, delegating automation management or approval process configuration), consider a governance model where additional System Administrator profiles are tightly controlled and monitored through login history and setup audit trails.

Wrapping Up

Delegated administration is one of those features that might seem minor on paper but has a significant impact on how smoothly a Salesforce org operates at scale. It bridges the gap between “everyone files a ticket for the admin” and “everyone is an admin” — neither of which is sustainable.

By creating well-scoped delegated groups, you empower regional managers, department leads, and IT support staff to handle routine tasks independently while keeping your org’s security posture intact. Combined with the profiles and permission sets we covered earlier in this series, delegated administration rounds out your toolkit for controlling who can do what in Salesforce — not just with data, but with the platform itself.

In the next post, Part 13 of the Salesforce series, we will look at List Views in Salesforce — how to create, customize, and share filtered views of your records to help users find the data they need quickly and efficiently.