Briefly: delegated administration lets a named group manage users within specific roles, assign a fixed list of profiles and permission sets, and administer named custom objects, without granting anything else. Genuinely useful for regional teams. Also one of the easiest ways to hand out full administrative power by accident, because a delegated admin can assign any permission set on the list, and permission sets can contain anything.
How a group is defined
Setup, Users, Delegated Administration, then a new delegated group. You fill in five sections.
- Delegated administrators. The users who get the power. Name them individually.
- User administration. The roles whose users they may manage, and implicitly all roles beneath those in the hierarchy.
- Assignable profiles. The profiles they may assign. If it is not on the list, they cannot grant it, and they cannot edit a user who already has it.
- Assignable permission sets. Same idea, and the section that deserves the most scrutiny.
- Custom object administration. Objects they may customise.
There is also a checkbox enabling the group for login access, which lets these administrators log in as the users they manage without asking permission first.
The risks, specifically
Permission sets are a blank cheque. A permission set is easy to create, easy to forget, and can contain Modify All Data, Manage Users or View All Data. Put such a set on the assignable list and your delegated admin can grant administrative power to anyone in scope. Review every assignable set line by line, and again when someone edits one, because editing a set does not require touching the delegated group.
The scope follows the role hierarchy. A group scoped to “EMEA Sales Manager and below” covers whatever sits beneath that role today. Reorganise the hierarchy, move a team under that branch, and the delegated group silently widens. Nothing warns you.
Login access without consent. That checkbox is a real impersonation grant. Actions taken while impersonating are recorded against the impersonated user, with the delegated administrator named in the Delegate User column of the Setup Audit Trail. That column is the only thing between you and a wrong conclusion during an investigation, so make sure whoever reviews the log knows it exists.
Custom object administration is production metadata change. Delegated administrators granted an object can add fields and change layouts and record types directly in production, outside your release process and outside version control. That may be fine for an internal admin-owned object. It is not fine for anything a package or an integration depends on.
When it beats a full admin profile
The case for delegation is strongest where the work is routine, high volume, and local knowledge matters: a regional operations team creating and disabling users for their own country, a franchise structure where each unit runs its own people, an acquired business with its own administrator during integration.
The alternative in each case is a ticket queue to a central team who cannot verify the request anyway, or full administrator access because it was easier. Delegation beats both.
Delegation is the wrong answer when the need is narrower than it looks. If a support desk only needs to reset passwords and release locked accounts, there is a permission for exactly that, and it is a far smaller grant than a delegated group. Check whether a targeted user management permission covers the requirement before building a group.
Running it safely
Keep the assignable profile list minimal, and never include a profile with administrative permissions. Keep the assignable permission set list shorter still, and give those sets names that make their contents obvious.
Name groups after the business unit rather than the person, review them quarterly against the current role hierarchy, and make the review a real one where somebody opens each assignable permission set. Log who asked for the group and why, because in two years nobody will remember.
Frequently asked
Can a delegated admin create a new profile or permission set? No. They can only assign what you have listed, which is the whole point of the feature.
Can they see or edit users outside their roles? No. Users outside the specified roles and their subordinates are out of scope, and so is any user holding a profile not on the assignable list.
Do delegated admins show differently in the Setup Audit Trail? Their own changes appear under their own username. The Delegate User column is populated when they act through Login As, which is a different thing and easy to confuse.
Can one user belong to several delegated groups? Yes, and the effect is cumulative. Two narrow groups can add up to something wider than either was meant to be, so review a person’s total scope, not each group in isolation.
