Replacing old groups with new ones

[Sandhya23]

If I have to replace the existing (functional) ServiceNow Groups with new ones, is it possible ? if yes what areas need to be considered and checked before doing so ?

Do we have any such check points to be referred ?

[Mark Manders]

Yes, you can, but the question you should ask is 'why'.

Groups contain roles and are used for assigning. They are used in (work)flows and scripts and in ACLs to enable people access. UI actions can have an 'isMemberOf' condition (and most annoying: it works with the sysID AND with the group name). So you really need to think about why you are doing this.

Can't you just rename them (you will still need to check scripted ACLs and UI action conditions that the name isn't used, but it will cause less issues). 

[J Siva]

Hi @Sandhya23 
We completed a similar migration last year. So, the first step is to identify the areas where this change will have a direct impact—such as Flow Designer (used to fulfill catalog tasks), knowledge article ownerships, CI ownerships, and any references to the old fulfillment groups (e.g., content within KB articles).
Once you've identified the potentially impacted areas, the next step is to plan how to replace the old groups with the new ones, either by using scripts or performing the updates manually.

Regards,
Siva

[Shraddha Kadam]

Yes, it is absolutely possible to replace existing (functional) ServiceNow Groups with new ones. However, it's a significant undertaking that requires careful planning and execution to avoid disruption. Here are the key areas to consider and check before doing so:

I. Identify all areas where the existing groups are used. This includes, but is not limited to:

• Assignment Rules: Where are these groups assigned automatically?
• Workflows/Flows: Are they used in approval workflows, task assignments, or other automated processes?
• Service Catalog Items: Are they fulfillment groups for catalog tasks or approvals?
• Notifications: Do notifications go to these groups?
• ACLs (Access Control Lists): Do these groups grant specific access to records or data?
• Reports and Dashboards: Are reports filtered or grouped by these existing groups?
• SLA Definitions: Do SLAs depend on these groups for assignment or escalation?
• Business Rules, Client Scripts, UI Policies, UI Actions: Are any custom scripts or configurations referencing these groups by name or Sys_ID? (Hardcoding groups is generally a bad practice but needs to be checked).
• Integrations: Are these groups used in any integrations with external systems?
• User Criteria: Are they used in User Criteria for knowledge bases, service portals, etc.?
• Queues: Are they linked to email queues for inbound actions?

II. Technical Considerations and Pre-Checks:

• Backup and Clone: Absolutely crucial! Before making any changes in production, clone your production instance to a sub-production environment (e.g., Dev, Test, UAT). This allows you to test the entire process thoroughly without impacting live operations.
• Test Environment: Ensure your test environment is as close to production as possible.
• Export Existing Group Data: Export the sys_user_group table data for existing groups, including their Sys_IDs, names, and any other relevant fields. This serves as a reference and a backup.
• Identify Group Members: Document the current members of each existing group (sys_user_group table) so you can accurately replicate membership in the new groups.
• Roles: Understand which roles are assigned to which groups. When creating new groups, ensure they have the appropriate roles.
• Group Types: If you use group types, ensure the new groups are assigned the correct types.
• Reporting: Analyze existing reports to see how they utilize group data.
• Scripting for Mass Updates: For large-scale replacements, you will likely need to use scripts (e.g., fix scripts, background scripts) to:
• Create the new groups.
• Migrate group members to the new groups.
• Update references to old groups in assignment rules, workflows, catalog items, etc., to point to the new groups.
• Caution: Exercise extreme care with scripts, and test them rigorously in non-production environments.
• Audit Trail: Ensure that your changes are properly recorded for auditing purposes.

III. Execution Steps (High-Level):

1. Create New Groups: Create the new groups in ServiceNow with the desired names, descriptions, and types.
2. Assign Roles to New Groups: Ensure the new groups have all the necessary roles that the old groups had.
3. Migrate Members: Add users to the new groups, replicating the membership of the old groups.
4. Update Dependencies: This is the most complex part. Systematically go through your identified dependencies and update them to point to the new groups. This might involve:
• Modifying Assignment Rules.
• Updating workflows and flows.
• Changing fulfillment groups in Service Catalog items.
• Adjusting notification recipients.
• Updating ACLs.
• Modifying reports and dashboards.
• Updating any custom scripts.
• Adjusting user criteria.
5. Deactivate/Deprecate Old Groups: Once you are confident that the new groups are fully functional and all dependencies have been migrated, you can deactivate (or potentially delete, but deactivation is safer for historical data) the old groups. Do NOT delete them immediately, as historical records might still point to their Sys_IDs.
6. Validate Historical Data: Understand how historical records (e.g., closed incidents, requests) that referenced the old groups will behave. Typically, these records will retain the Sys_ID of the old group, so their "Assigned to Group" field will still show the old group's name. If you deactivate the old groups, you might want to consider archiving old records or implementing a strategy for historical reporting.

1. Post-Replacement Checks:

• Regression Testing: Thoroughly test all affected processes, including:
• Incident/Request creation and assignment.
• Approval workflows.
• Service Catalog fulfillment.
• Notifications.
• Reporting.
• User access to data and functionalities.
• Monitor System Performance: Ensure the changes haven't introduced any performance degradation.
• User Feedback: Collect feedback from users to identify any unforeseen issues.
• Documentation: Update all relevant documentation to reflect the new group structure.

Replacing ServiceNow groups is a substantial administrative task that should be approached with a structured project management methodology. Thorough planning, testing, and communication are key to a successful transition.