Can someone explain the Reassignment Counter?

scottatah · ‎01-15-2014

To me:

a reassignment count of 0 would mean the assignment group was set but never changed.

a reassignment count of 1 would mean the assignment group was set and then changed.

While attempting to use the reassignment counter with some reporting, I started to notice that I cannot actually spot a difference between an incident with a count of 0 or 1. In either case, I can only see the assignment_group being set once. Am I missing something or are there other variables that play a part in this?

guy_yedwab · ‎01-15-2014

The business rule that triggers this ("reassignment counter", on the task table) is incredibly simple. This is the condition that triggers it:

current.assignment_group.changes()

This is what it does:

current.reassignment_count += 1;

And it is only triggered by updates.

Because of how simple the business rule is, there's only one thing I can think of that would cause a discrepancy: if the Incident is inserted with no assignment group, then populating an assignment group the first time would be "Reassignment = 1". Whereas if the incident is created WITH an assignment group (or if assignment rules provided one), the reassignment count would be "Reassignment = 0".

Let me know if that's what you're seeing. I think the logic behind this is that if the incident started with no assignment, and had to be assigned after the fact, that does technically mean there was some intervention before it reached the person it was supposed to reach.

If you want to make it so that you're only tracking from the second assignment group it reaches, you could add this to the condition:

&& previous.assignment_group

(I think... I haven't tested it).

Let me know if I'm understanding the discrepancy right. Otherwise, something more subtle might be at work.

View solution in original post

rc393g · ‎05-28-2015

Hi Lucien/All,

I tried and used your report list above it is very good.

Now, we are trying to capture the reason of reassignment from one group to another. So I added the Assignment Reason in the list but it seems the report list only captures the last Assignment Reason set.

For Instance, Assignment Reason selected are

1. On - Leave

2. Escalation

3. Wrong Assignment

The one showing on the report for three rows is only Wrong Assignment. Would you know how we can also capture the history of the Assignment Reason? Thank you.

harikrish_v · ‎06-27-2014

Hi Scott,

By default, since incident table is audited, changes you make to any of the fields on the table is actually logged in sys_history_line table. Below is a query that you can use to find out which all incidents where reassigned atleast once. I hope this helps your cause someway

var gr=new GlideRecord('sys_history_line');


gr.addQuery('field','reassignment_count');


gr.addQuery('new','!=','0');


gr.query();


while(gr.next()){


gs.log('Reassigned Incidents:'+gr.set.getDisplayValue());


}

Thanks & Regards,

Hari

rc393g · ‎05-28-2015

Hi Hari,

Is the script also good for Eureka version? And where should we perform this. Thank you!

Marta Connor · ‎01-28-2022

In the reporting there are two fields named:

1 -

2 -

Both show different values in the same report.

Can anyone explain what is the difference between these two?

Thanks