Can someone explain the Reassignment Counter?

scottatah
Giga Expert

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?

1 ACCEPTED SOLUTION

guy_yedwab
Kilo Guru

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

13 REPLIES 13

guy_yedwab
Kilo Guru

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.


If the incident was inserted with assignment group filled in, why wouldn't this business rule run and add an increment of 1 once the assignment group changes to another value when updated (as in resolved and sent to another group to close).


sid23
Mega Contributor

Hi guy.yedwab<

I understood the functionality behind the reassignment count but i also want to include the same on my case form as a read only field. When i try to pull in the field from slush bucket onto my form it is not appearing. Do you have any suggestions?

 

Thanks

Lucien1
Giga Expert

Hi Scott,



In simple terms, are you trying to create a report that shows a call that has been assigned by EG, the service desk and then gets transferred to desktop support?



The report I have looks at a call that has been assigned to 1 group and transferred to another group with how long each group had the ticket in their queue.



If this is what you are after let me know and I will dig it up and send this over to you.



Regards,



Lucien