The Vanishing Assignment Group After a Mid-Sprint Reorg
A 400-person organization runs a single ServiceNow instance. The IT support team was reorganized: the old group Desktop Support (containing 60 users) is being split into Tier 1 Support and Tier 2 Support. The admin creates both new groups, copies the 60 members into them, then deactivates Desktop Support. Within a day, 120 open incidents that were assigned to Desktop Support become invisible to agents' default list views, and the SLA engine starts flagging them as unassigned. The admin's manager asks why the records 'disappeared' and wants them reassigned to the new groups by end of day. A junior admin suggests just reactivating the old group to make the records reappear.
1. Explain why the incidents became 'invisible' and why the SLA engine treated them as unassigned. What is the safest remediation?
Read the worked answer
The records did not lose their assignment_group reference - they still point to the now-inactive Desktop Support group. What changed is visibility: many default list filters and the agent workspace restrict to active assignment groups, and role/group-based query filters often exclude inactive groups. The SLA engine's 'unassigned' behavior is a symptom of the same condition: SLA definitions and assignment logic commonly check for an active group, so an inactive group reads as effectively unassigned.
Safest remediation: do not reactivate the group as a permanent fix - that just defers the split. Instead:
- Build a one-time reassignment: filter incidents where
assignment_group = Desktop Supportandactive = true, then bulk-updateassignment_groupto the correct new group. Bulk update via list is fine for a few hundred rows; for larger sets use a scheduled job or transform. - Decide the mapping rule (e.g., by category, priority, or assigned-to's new group) rather than dumping all 120 into one new group.
- Keep the old group inactive but do not delete it - historical records and audit trails reference it.
- Add a data-integrity check (scheduled report) for open records pointing at inactive groups.
Reactivating temporarily to restore visibility is acceptable only as a stopgap while the reassignment runs, and must be paired with a hard deadline to deactivate again.
2. A junior admin proposes adding all 60 users to both new groups so 'nobody loses access.' Evaluate this.
Read the worked answer
This is a classic access-creep trap. Putting every user in both Tier 1 and Tier 2 means:
- Role inheritance doubles: any role granted to either group is now held by all 60 users, violating least privilege.
- Assignment ambiguity: records can be assigned to either group, and agents see queues they shouldn't, inflating perceived workload.
- Reporting corruption: group-based metrics (resolution time per tier) become meaningless because membership overlaps.
The correct approach is to map each user to exactly one tier based on their actual function, using the reorg data. If some users genuinely need cross-coverage, grant that through a narrowly-scoped role or a temporary, time-boxed membership with an expiry, not permanent dual membership. Verify with a group-membership report and a role-inheritance audit before closing the change.