Renaming group name - Best Practice

[MThomas1]

Hello,

We have requirement to rename a group name  that is in use for around 8 years , tickets, tasks, etc are associated with the group.

     - what is the best practice ?

    - whether renaming automatically roll across configurations/references/hard coded settings etc  

    -  impact on current workflows or other configurations

    -  AD integration impact for user/group import.

    -  impact of existing /closed REQ/RITM/SCTASK for the group

    -  Notifications set up

    -  Best Practice/recommendation

     - renaming vs creating a new group ? 

     - orphan records

     - auditing etc 

Thank you and appreciate your input on this request.

[GlideFather · Accepted solution]

Hi @MThomas1,

There are many aspects to cover but what goes first on my mind with renaming is to have the historic data saved somewhere.

To achieve this if you are going to rename some groups, I would recommend to do one or two of the following steps:

• enable auditing on the [sys_dictionary] for [sys_user_group]
  • to have chance to retrospectively check the original/previous name at [sys_audit] table,
  •  on the sys_dictionary select a table and a field whose changes you want to be able to see in the future and change corresponding value in the Audit to true as seen below,
  • if Audit is true that means that changes made to records on that table will be audited at sys_audit table:

• add the legacy name to description and/or to a custom read-only name,
  • to have chance to see the old name if needed (documentation, reporting, team chats might contain the old name so to know it's really that group),
  • eventually add a timestamp when it was renamed,
  • something like this:

Consider what works better for you, the audit option is for more technical users (admins, developers) while the old name copied to description can be visible to all people who will see the records. Or both...

Regarding your question whether it is better to create new groups or rename, it will depend on how your data are processed, owned and what do you plan in the future. You should NOT delete any records, as they might be associated with existing records (e.g. assignment group on an incident), if you would delete that group, it would no longer be visible (the field wouldn't be empty, but wouldn't display anything)...

Let me know how does it sound to you and if you want to brainstorm about something else

[Tanushree Maiti · Accepted solution]

Hi @MThomas1 

Servicenow reads every record by their sys_id.

If you rename the group I can foresee there could be 2 cases where impact is there.

1. Impact 1: If in your instance , you have followed bad practice like hard coded group name  instead of Group sys_id in scripts.

Solution: Analysis your instance. Replace the hard coded group name by group sys_id in place like ACL script, workflow script ( if you have old instance), script include etc 

Impact 2: If you have coalesce on group name field, then it would result in new group Creation!

Probable Solution: Set coalesce on SSID, which is one of the attribute of active directory object. You will require to map it to some field on SN or create a new field on group table to map it

Steps:  Create a New Custom Field 

1. Add the AD Attribute to LDAP Config:  add the SSID  attribute to the Attributes list on the LDAP Server record in ServiceNow.
2. Create the Custom Field:
   • Navigate to System Definition > Tables and find the sys_user_group table.
   • Go to the Columns related list and click New to create a custom field (e.g., u_ad_ssid).
   • Set the Type to(String)
3. Configure Transform Map (Mapping Assist):
   • Open your existing LDAP Group Import Transform Map (navigate to System Import Sets > Administration > Transform Maps).
   • Use the Mapping Assist feature to map the source field (e.g.,u_ssid) to your new custom target field (e.g., u_ad_ssid).
   • Ensure the Coalesce checkbox is marked for this specific field map.

[GlideFather · Accepted solution]

Hi @MThomas1,

There are many aspects to cover but what goes first on my mind with renaming is to have the historic data saved somewhere.

To achieve this if you are going to rename some groups, I would recommend to do one or two of the following steps:

• enable auditing on the [sys_dictionary] for [sys_user_group]
  • to have chance to retrospectively check the original/previous name at [sys_audit] table,
  •  on the sys_dictionary select a table and a field whose changes you want to be able to see in the future and change corresponding value in the Audit to true as seen below,
  • if Audit is true that means that changes made to records on that table will be audited at sys_audit table:

• add the legacy name to description and/or to a custom read-only name,
  • to have chance to see the old name if needed (documentation, reporting, team chats might contain the old name so to know it's really that group),
  • eventually add a timestamp when it was renamed,
  • something like this:

Consider what works better for you, the audit option is for more technical users (admins, developers) while the old name copied to description can be visible to all people who will see the records. Or both...

Regarding your question whether it is better to create new groups or rename, it will depend on how your data are processed, owned and what do you plan in the future. You should NOT delete any records, as they might be associated with existing records (e.g. assignment group on an incident), if you would delete that group, it would no longer be visible (the field wouldn't be empty, but wouldn't display anything)...

Let me know how does it sound to you and if you want to brainstorm about something else

[Tanushree Maiti · Accepted solution]

Hi @MThomas1 

Servicenow reads every record by their sys_id.

If you rename the group I can foresee there could be 2 cases where impact is there.

1. Impact 1: If in your instance , you have followed bad practice like hard coded group name  instead of Group sys_id in scripts.

Solution: Analysis your instance. Replace the hard coded group name by group sys_id in place like ACL script, workflow script ( if you have old instance), script include etc 

Impact 2: If you have coalesce on group name field, then it would result in new group Creation!

Probable Solution: Set coalesce on SSID, which is one of the attribute of active directory object. You will require to map it to some field on SN or create a new field on group table to map it

Steps:  Create a New Custom Field 

1. Add the AD Attribute to LDAP Config:  add the SSID  attribute to the Attributes list on the LDAP Server record in ServiceNow.
2. Create the Custom Field:
   • Navigate to System Definition > Tables and find the sys_user_group table.
   • Go to the Columns related list and click New to create a custom field (e.g., u_ad_ssid).
   • Set the Type to(String)
3. Configure Transform Map (Mapping Assist):
   • Open your existing LDAP Group Import Transform Map (navigate to System Import Sets > Administration > Transform Maps).
   • Use the Mapping Assist feature to map the source field (e.g.,u_ssid) to your new custom target field (e.g., u_ad_ssid).
   • Ensure the Coalesce checkbox is marked for this specific field map.

[jeffreybell · Accepted solution]

     - what is the best practice ?

This really depends on your organization, what works best for you.  I would put some effort into designing governance around this with your platform team.  Some folks will encode certain functions in the name etc.  However, if you are asking if 'how' to change it then you are generally safe to just change it in the 'name' field (with caveats see below)  GlideFather also gave a pretty great technique where you can save the historic data via auditing.

    - whether renaming automatically roll across configurations/references/hard coded settings etc  

Yes and No,  if the references are by 'sys_id' you will be just fine.  Any hard coded references to the name itself or any conditions built off a hard coded value that expect a specific string value will fail.  For example if you had a piece of code 

<sys_id> === 'my_group_name'

 Expect this to fail.  However, good news is you can use the 'Code Search' tool within your instance to find these occurrences and clean them up (View Pradeep Sharmas Article: https://www.servicenow.com/community/developer-blog/using-code-search-to-make-developing-on-the-plat... )

    -  impact on current workflows or other configurations

See the above mentioned sys_id, everything is tied to the sys_id

    -  AD integration impact for user/group import.

Anything that is being integrated into AD should be changed in AD as AD is the source of truth.  If you are using something like a transform map, you would be coalescing on the AD GUID which your groups sys_id would be related to the AD GUID so you would just be changing the label everything under the hood will still function.  I always encourage reviewing your design/process/governance to find a better way rather than just lifting and shifting.

    -  impact of existing /closed REQ/RITM/SCTASK for the group

Depending on your implementation and level of customizations this would be trivial as the sys_id is referenced for the group and then retrieves the 'display name'.   This wouldn't create orphans OOTB unless you had some customizations.

    -  Notifications set up

Notifications referencing the group via reference fields will continue to function. However, any encoded queries, scripts, or notification conditions using the group name should be reviewed.

    -  Best Practice/recommendation

I don't know your architecture/governance/design, however here are some fairly basic guidelines I would recommend based on some practical experience I have: 

1. Verify how the AD transform map coalesces groups.
2. Search for scripts or configurations referencing the group name.
3. Rename the group in AD (source system).
4. Allow the next group import to update ServiceNow.
5. Validate assignment, notifications, and integrations.

     - renaming vs creating a new group ? 

Renaming is preferred when only the name changes. Creating a new group should be done only if there is a structural or ownership change (different team, responsibilities, or membership)

OR

If you inherited an environment that has not had governance, had neglected systems administration or needs to be unwound from a high amount of customization

     - orphan records

Previously, answered

     - auditing etc 

I like GlideFather's recommendation