ServiceNow Group Manager: The Manager Field, the Group Manager Role, and Multiple Group Managers

The Manager field on a ServiceNow group grants no permissions whatsoever. Naming somebody the group manager does not let them add a member, remove a leaver, approve anything, or see a report. It is an informational reference field that other configuration can read, and out of the box almost nothing reads it. That gap between what the field is called and what it does is why so many teams hand a manager the field, tell them they now own their group, and then field a ticket a week later asking why the Edit button is missing. Here is what the field really is, the exact configuration that makes it functional, and why you cannot simply name two people.

What the ServiceNow group manager field actually does

Manager is a single reference field on sys_user_group pointing at a sys_user record. That is the entire definition. Long-running ServiceNow Community threads asking what the field is for land on the same answer with some frustration: it is there because it says what it is, the manager of the group, and it exists for information rather than for enforcement. One response puts it plainly, describing the field as purely for information purposes.

So what does read it? Things you build. Notification rules that email the group manager when an SLA is about to breach. Approval flows that route to the manager of the assignment group on the record. Reports that group open work by owning manager. Reference qualifiers on other fields. All of that is legitimate and common, and all of it is configuration somebody wrote in your instance rather than behavior ServiceNow ships.

What it does not do is grant a role, unlock a UI action, or change an ACL result. The manager of a group has exactly the access their roles give them, which for a typical fulfiller is the itil role and nothing about group administration. This is the correct security design, and it is still a surprise every single time.

How to let a group manager manage their own group membership

This is the request that arrives about a month after somebody starts filling in the Manager field seriously. The team wants managers to maintain their own rosters so the platform team stops being a ticket queue for adding people to groups.

Membership lives on sys_user_grmember, a separate many-to-many table, so that is where the access control has to go. The well established pattern, documented by ServiceNow Guru and reused across a lot of instances, is three ACLs on that table plus a business rule as a safety net.

The write and delete ACLs on sys_user_grmember carry a script condition:

if (gs.hasRole('user_admin') || current.group.manager == gs.getUserID()) {
    answer = true;
}

That grants the operation to platform administrators holding user_admin, and to whoever is named in the Manager field of the group the membership row belongs to. The create ACL is the awkward one, because creating a row means there is no existing record whose group manager can be checked, so it has to be opened by role, typically to itil. That is wider than anybody wants, which is why the pattern includes a backstop.

The backstop is a business rule, commonly named Restrict Changes to Group Managers, that aborts anything the ACLs let through:

if (!gs.hasRole('user_admin') && current.group.manager != gs.getUserID()) {
    gs.addErrorMessage('You do not have permission to modify this group membership.');
    current.setAbortAction(true);
}

Finally, so managers are not staring at buttons that will reject them, the Omit Edit Condition on the Group Members related list uses the same logic to hide the Edit button from users who are not the manager of that group.

Four pieces, none of them large, and every one of them is custom. Budget the testing rather than the build: the failure mode is a manager who can add people to a group they do not manage, and you will not notice that from the happy path.

Why user_admin is the wrong shortcut

The tempting one-line answer to all of this is to give the managers the user_admin role and move on. It does work, immediately, which is exactly why it keeps happening.

It also gives every one of those managers the ability to administer users and groups across the whole platform. They can edit any group, change any group's manager including their own, add themselves to groups that grant roles, and modify user records. On an instance where groups grant roles, and most instances do because granting roles to groups rather than individuals is the standard recommendation, that is a privilege escalation path with a friendly name. It is scoped to nothing.

The ACL pattern above exists specifically so that a manager's power stops at the edge of the group they manage. If you are going to delegate membership, delegate it narrowly. And whichever route you take, write down who can change group membership and how that is evidenced, because access review season arrives whether or not the model was designed for it, and a delegation nobody documented is the one that turns into a finding. Teams running formal control frameworks usually end up needing to map that permission to a control they can actually evidence rather than reconstructing it from ACL scripts a year later.

Can you have multiple group managers in ServiceNow?

Not out of the box. The Manager field accepts one sys_id at a time, because it is a reference field rather than a list. There is no secondary manager field in the baseline platform either, and community reports of looking for one confirm it is absent, with the caveat that this varies by version and by which plugins are active.

There are three real options and they are not equally good.

On Field Service Management specifically, a work group or assignment group supports a single manager by default unless you have Workforce Optimization, and managers there need the wm_manager role. If you are on FSM and want real multi-manager behavior, that is the supported road rather than a dictionary change.

What breaks when you convert Manager to a list

The dictionary change is one click and it deserves more thought than it gets, because the thing it breaks first is the thing you probably built last.

Go back to the ACL condition above: current.group.manager == gs.getUserID(). That comparison works because dot-walking a reference field returns one sys_id and the equality test is meaningful. Convert Manager to a list and the same dot-walk returns a comma-separated string of sys_id values. A single user's ID will not equal that string unless there happens to be exactly one manager, so your delegated membership administration quietly stops working for every group with two managers, which is the entire reason you made the change.

The same pattern repeats everywhere the field is read. Notification recipients defined as the group manager, approval rules routing to the manager, reference qualifiers filtering on manager, reports grouping by manager: each of those needs revisiting, and none of them will throw an error. They will just match nothing, or match the wrong thing, and the first sign will be a missed approval.

If you do go this route, search for every reference to the manager field before you flip the dictionary, and convert equality tests to list membership tests. If you cannot complete that inventory confidently, the custom secondary field in the table above is the safer purchase of the same outcome.

How to change group managers in bulk

Reorganizations make this a routine job rather than a one-off. Updating hundreds of groups by hand through the form is where transcription errors come from, so do it as a query.

A background script or a fix script running a GlideRecord query against sys_user_group, filtered to the groups you mean and setting the new manager sys_id, handles it in seconds. Two cautions worth applying every time. Filter on something durable such as the group type or a naming convention rather than a list of names typed by hand, and run the query first with gs.info printing the matches before you add the update call, so you can read what you are about to change. On a table this central, a query that matches more groups than you expected is not a small mistake.

The related governance question is who is allowed to run that at all. Changing a group manager changes who can administer that group's membership under the delegation pattern above, so the manager field becomes a security-relevant field the moment you build on it. It belongs in the same review as role assignment.

The manager who left, and the group nobody is watching

The most common real world state of the Manager field is worse than empty: it is filled in with somebody who left the company eighteen months ago. Empty at least reads as unowned. A stale name reads as owned, and every report and notification built on it points at an inactive user who receives nothing.

This compounds with how membership behaves. Deactivating a user does not remove their group membership rows, so a group whose manager has left keeps its departed members too, and nothing on the platform flags either condition. The group looks staffed and governed and is neither. Worse, removing a member deletes the membership row outright, so the table holds no history at all and you cannot reconstruct who was in the group when the manager was last active.

The maintenance task that fixes this is small and almost nobody schedules it. Run a report over active groups where the manager is empty or references an inactive user. Run a second one over active groups whose active member count is zero. Both are five-minute report builds and both find things on every instance they are pointed at. Pair them with a group type scheme that is actually enforced by reference qualifiers and the group model stops decaying between reorganizations.

When the group manager is the wrong unit of control

Step back from the field for a moment and look at what the delegation is trying to achieve. The reason teams want group managers to own their rosters is that the roster is the routing rule. Who is in the group determines who can be assigned, so membership is the only lever a manager has over how work reaches their team.

That is a blunt lever. It is a binary in or out, with no way to say that somebody is on shift today, at capacity already, half time, in training on this product but not that one, or should take a proportionally smaller share this sprint. A manager who wants any of those outcomes has to express them by adding and removing people from a group, which is why rosters churn and why assignment groups drift out of shape within a couple of years.

ServiceNow's own answer to this is Advanced Work Assignment, which pushes work to a person based on availability, capacity and skills rather than dropping it in a queue. It is a real answer and worth understanding what it takes to run, both in configuration and in entitlement.

Assigner is the lighter version of the same idea, running beside the ServiceNow you already have. ServiceNow stays the system of record and keeps the incident, the CMDB and the reporting. Assigner decides who inside the group, using true circular round robin, weighted rotation so a half-time engineer carries half the load by design, enforced workload limits, skill matching and live availability. Every assignment records the rule, the candidates considered and the reason, so a manager adjusting how work reaches their team edits a rule instead of editing a roster, and the answer to why did this go to her is one line rather than a reporting project. Pricing starts at $12 per user per month billed yearly ($15/mo billed monthly), and the AI assists while the rules stay yours.

The short version

• The Manager field on sys_user_group is a single reference to a user and grants no permissions at all. It is informational, and only configuration you wrote reads it.
• To let managers maintain their own rosters, add write, delete and create ACLs on sys_user_grmember conditioned on gs.hasRole('user_admin') || current.group.manager == gs.getUserID(), back them with a business rule because the create ACL has to be opened by role, and hide the Edit button with an Omit Edit Condition.
• Do not hand out user_admin instead. It is platform-wide user and group administration and, on an instance where groups grant roles, an escalation path.
• Multiple managers are not supported out of the box. A custom secondary list field is the safest route. Converting the Manager dictionary entry from Reference to List breaks every equality comparison against it, starting with the ACL above.
• Audit for stale managers and empty groups. Deactivating a user removes neither, and nothing on the platform flags either one.