Offboarding ServiceNow users

[SusanWinKY]

We have an automated process via our identity management system to inactivate a ServiceNow user when he/she separates from the company.   This automatically removes the user from any groups and roles.   However, that does not take into account any open tickets, tasks, approvals, requested items, VTBs, Live Feeds, Reports, Dashboards, etc. that the user created or owns.   We're not sure if we want reassign those things, or perhaps just create a notification to the user's manager.

1. Has anyone put into place a way to thoroughly offboard ServiceNow users in the way I've described?   What have you done?   Is there anything we should consider when doing this?
2. Is there any report we could create that would show us all the places the user is currently engaged in?   Again, I'm referring to the user's open tickets, tasks, approvals, requested items, VTBs, Live Feeds, Reports, Dashboards, etc.

[Uncle Rob]

I've never gone as thorough as scouring VTB, Live Feeds, Reports, and Dashies.

I *DO* make it a priority to handle tasks that a user is the "client" of, and also tasks they are assigned.

In the first case I send a notification to the Assigned To of the task informing them the user may no longer exist and to assess if closure is appropriate.

In the latter case I assign the tickets back to the group with an added Work Note.

[User657785]

Hi Susan,

Would love to know if you ever came up with a solution for your offboarding and how you went about it? What checks did you make? What action was taken on each ticket or asset etc..

Here are some rough notes I am writing now that I would think need to be looked at:

• ServiceNow user account creation
• BR creates user entitlement (E3 licence)
• ServiceNow user account update
• BR runs only if the active field changes (active / inactive)
• If account is made inactive
• BR removed user entitlement
• If account is made active
• BR checks user has entitlement
• If no E3 entitlement, then creates the entitlement
• What else always or almost always needs to be done when a user account is created? (Other entitlements? Anything else in ServiceNow?)
• What else needs to be done when a user if offboarded?
• Do all entitlements need to be removed?
• Other software licences?
• Do assets need to be removed or reassigned to another person? (team leader? Except if team leader is CEO or manager?? Etc etc..)
• Open tickets reassigned to team leader? (if assigned to)
• Open tickets, notification sent to team leader (if user is requested for)
• Remove user from ServiceNow groups
• Remove user from ServiceNow roles
• Remove or reassign approvals?

[Inactive_Use683]

For offboarding, we get input from 2 sources:

1. Our IDM system lets us know the user has been deactivated.

2. Our HR system sends an email with the deactivated user's info.

For scenario 1:

1. We set active=false on the user record, which triggers a BR to add a work note to records (not everything, we selected which ones are important) that the user opened and that the user is assigned to.  The usual email notifications then alert the assignment group that a work note was added to the record.  The work note is something like "The user (user name) who was assigned this ticket was recently deactivated from ServiceNow. Reassign the ticket to a different user." or "The user (user name) who submitted this ticket was recently deactivated from ServiceNow. This ticket may no longer be valid. Please assess whether the ticket should remain open. If it is no longer needed, resolve it with an appropriate closure note."

2. We do NOT automatically remove the deactivated user from any groups/roles they are in.  We delay that by 14 days because we have a scenario where a user may need to be temporarily deactivated, then reactivated.

For scenario 2:

The email generates 1 or more RITMs on behalf of the deactivated user's manager.  The purpose of is to:

1. Identify all assets of particular classes that are assigned to the user (i.e., computers, mobile devices but could be easily expanded to other classes).  An RITM is generated for each asset.  The team assigned to the tasks on the RITMs collect the user's devices from the manager, cleanse the data on them, and update data in the CMDB.  AT this time they may also deal with any software licenses assigned to the user.  We aren't currently managing software licensing in SN though.

2. Alert various teams to disable access for the user's accounts.  This includes badge access, voicemail access, scrambling the user's passwords, and similar updates.  One RITM with multiple tasks is created.

For onboarding, we create a user account in SN with whatever data the IDM feed sends us and auto-add them to a particular group that everyone gets added to. We don't auto-allocate anything else in SN or auto-create any catalog requests for the user or user's manager.

We have a lot of potential to automate some of this stuff (particularly removing accesses and possibly updating CMDB data) but the teams are happy with what they have for now.  It's MUCH better than where we were a few years ago which was all email based with no tracking.

[SusanWinKY]

For offboarding, we get input from 2 sources:

1. Our IDM system lets us know the user has been deactivated.

2. Our HR system sends an email with the deactivated user's info.

For scenario 1:

1. We set active=false on the user record, which triggers a BR to add a work note to records (not everything, we selected which ones are important) that the user opened and that the user is assigned to.  The usual email notifications then alert the assignment group that a work note was added to the record.  The work note is something like "The user (user name) who was assigned this ticket was recently deactivated from ServiceNow. Reassign the ticket to a different user." or "The user (user name) who submitted this ticket was recently deactivated from ServiceNow. This ticket may no longer be valid. Please assess whether the ticket should remain open. If it is no longer needed, resolve it with an appropriate closure note."

2. We do NOT automatically remove the deactivated user from any groups/roles they are in.  We delay that by 14 days because we have a scenario where a user may need to be temporarily deactivated, then reactivated.

For scenario 2:

The email generates 1 or more RITMs on behalf of the deactivated user's manager.  The purpose of is to:

1. Identify all assets of particular classes that are assigned to the user (i.e., computers, mobile devices but could be easily expanded to other classes).  An RITM is generated for each asset.  The team assigned to the tasks on the RITMs collect the user's devices from the manager, cleanse the data on them, and update data in the CMDB.  AT this time they may also deal with any software licenses assigned to the user.  We aren't currently managing software licensing in SN though.

2. Alert various teams to disable access for the user's accounts.  This includes badge access, voicemail access, scrambling the user's passwords, and similar updates.  One RITM with multiple tasks is created.

For onboarding, we create a user account in SN with whatever data the IDM feed sends us and auto-add them to a particular group that everyone gets added to. We don't auto-allocate anything else in SN or auto-create any catalog requests for the user or user's manager.

We have a lot of potential to automate some of this stuff (particularly removing accesses and possibly updating CMDB data) but the teams are happy with what they have for now.  It's MUCH better than where we were a few years ago which was all email based with no tracking.