Incident and reassignment

[Sue L]

Does anyone do this?  Is it a good idea? We have a new ServiceDesk keen on incident metrics, especially if they pertain to them.  

We are looking for a way to capture the reason for an incident to be re-assigned. Perhaps it's a field on the incident form with a selectable list of 4-5 items (no support info; incorrect routing; no access to fix; etc).

As incidents may get re-assigned multiple times: it's not likely to work well to have a static field at the top of the incident, unless it is able to be used multiple times during the life of an incident (selecting again, inserts the info to the Activity Log or something).

Basically need to know if this is something OOB (doubtful) that we could add, or if not OOB, if there is a reasonable way to accommodate it.

[Kieran Anson]

Hi,

It's not something OOTB but it's a requirement I've seen implemented a few different instances in instances I've come across.  

In several of those instances, I've removed the functionality. The idea sounds nice, but what actual benefit does it provide? If there's no close loop process it's just another piece of data your support teams have to populate to get to the point of resolving the ticket. That friction quickly devalues it.

Now, in terms of doing this I see two equally valuable options. Both focus on Workspace UI

1. Make the assignment group read only and implement a "reassign" declarative action. This produces a model that asks for the new assignment group, and the reason as a drop-down. You can then capture the reassignment details as some form of metric in another table. 

2. Allow the assignment group field to be modified, but on change produce a pop up immediately to capture the reason why 

[Tanushree Maiti]

Hi @Sue L 

You can achieve it using customization.

• To capture a reassignment reason in ServiceNow, create a custom choice field  with choices (no support info; incorrect routing; no access to fix; etc).
• Configure a UI Policy/Business Rule to make it mandatory when the Assignment Group changes.
• Use a Business Rule - to log this repeatedly during a ticket's lifecycle and copy  the selected reassign reason to the Activity Log upon save and resets the field

[mza-guille]

Hi Sue,

Yes, I have seen this requirement before, but I would be careful with how it is implemented.

I would not use one static field on the Incident as the final reporting source. That field only represents the latest value, and reassignment can happen multiple times during the life of the ticket. You would either lose history or need awkward logic to copy/reset it.

A better design is to treat each reassignment as an event:

• Incident
• Previous assignment group
• New assignment group
• Reassignment reason
• Optional comments
• Changed by
• Changed date/time

That can be a small custom child table or a metric-style table. Then every assignment change creates one row. Reporting becomes much cleaner because you can answer questions like:

• Which groups are receiving incorrectly routed Incidents?
• Which source groups reassign most often?
• What are the most common reasons?
• How many reassignments happen before resolution?

For the user experience, I would avoid asking agents to fill a reason on every save. Only prompt when Assignment group actually changes. In Workspace, the cleaner option is usually a controlled “Reassign” action/modal where the agent picks the new group and reason together. In classic UI, the same idea can be done with client-side validation plus a server-side rule that writes the reassignment event.

The biggest process warning is this: do not collect the reason unless someone owns the follow-up process. Otherwise it becomes another mandatory field that agents fill with the fastest option just to move the ticket. If ServiceDesk wants the metric, I would define the reason list very tightly and review the results regularly to improve routing rules, catalog forms, assignment rules, or knowledge gaps.

So my recommendation would be:

• Do not use a single static Incident field as the system of record.
• Capture one reassignment reason record per assignment-group change.
• Prompt only at the reassignment moment.
• Keep the choice list small.
• Use the data for a closed-loop improvement process, not just individual/team scoring.

That gives you the reporting value without damaging the Incident form or losing reassignment history.