The CreatorCon Call for Content is officially open! Get started here.

Report on tickets 'touched' or 'handled' by an Assignment Group

elbow
Giga Contributor

Hi All,

I've read several similar questions and been through the answers. Needless to say I'm left needing to ask my own question.

I want to use the OOTB Reporting module (version=helsinki) to report on all tickets assigned to a group (I'll actually use a Parent group, and pivot the results by each child group), which have specifically been 'touched' or 'handled' by another particular team. Let's call that team "Team Z"

I can confirm that Team Z will actually add a Work Note such as "Assigned to Team A" to every ticket they 'touch' or 'handle'. So not only will they have an entry in the History table, it also appears in Notes. This may assist in your ideas/responses.

So lets say last month there were a total of 200 tickets assigned to, and closed by Team A.

I want to be able to tell how many of them had passed through the Team Z queue prior.

I know there is a reassignment count also, but not sure it's going to help me out in this case. I'm presently fiddling using the 'keyword' function but I've read the Notes table is not indexed so I could potentially create a vortex if I continue. And of course, I've noticed I can't 'layer' keyword criteria in a single query, or use the AND function. (I take it this is a known limitation?)

Any help is appreciated. I should repeat that I need to run this in the gui itself. That said, if the only way the above can be achieved is by direct query then don't hold back!

And if you need me to clarify anything, or add information please let me know.

Thanks in advance,

Scott

1 ACCEPTED SOLUTION

Hey Scott, this should get you what you're looking for.



Create a metric called something like Incident Touched.   Use the following settings:


  • Name: Incident Touched
  • Table: Incident [incident]
  • Field: Assignment group
  • Type: Script calculation
  • Timeline: (leave blank)
  • Active: True (checked)
  • Description: Creates a metric to record that an assignment group touched an incident. Does not create duplicate metrics if an incident is assigned to an assignment group multiple times.
  • Script: See below


Script:


/**


* Creates a metric to record that an assignment group touched an incident.


* Does not create duplicate metrics if an incident is assigned to an


* assignment group multiple times.


*


* Parameters


*   These parameters are passed into all metric definition scripts.


*


*   current


*       The current record that triggered the metric definition


*


*   definition


*       The metric definition being triggered


*


*   mi


*       A MetricInstance object (see the MetricInstance script include for more


*       information and documentation). I'm not a big fan of using the mi object


*       because it doesn't really contain complete functionality or the ability


*       to customize metrics to the extent that a custom script normally


*       demands.


*


* Created by Dennis R


* 2017-08-16: Initial creation


*/


(function calculateMetric(current, definition, mi) {


      // Check to see if a metric instance already exists for this ticket


      // assigned to this assignment group


      var grMetric = new GlideRecord('metric_instance');


      grMetric.addQuery('id', current.getValue('sys_id'));


      grMetric.addQuery('definition', definition.getValue('sys_id'));


      grMetric.addQuery('value', current.getDisplayValue('assignment_group'));


      grMetric.query();




      if (grMetric.hasNext()) {


              // If so, then this ticket has already been counted for this assignment


              // group and there's no need to do anything.


      }


      else {


              // If not, create one


              var now = new GlideDateTime();


              var instant = new GlideDuration(0);


           


              grMetric = new GlideRecord('metric_instance');


              grMetric.initialize();


              grMetric.setValue('table', current.getRecordClassName());


              grMetric.setValue('id', current.getValue('sys_id'));


              grMetric.setValue('definition', definition.getValue('sys_id'));


              grMetric.setValue('field', definition.getValue('field'));


              grMetric.setValue('value', current.getDisplayValue('assignment_group'));


              grMetric.setValue('duration', instant);


              grMetric.setValue('business_duration', instant);


              grMetric.setValue('calculation_complete', true);


              grMetric.setValue('start', now);


              grMetric.setValue('end', now);


              grMetric.insert();


      }


})(current, definition, mi);


(You won't hurt my feelings too much if you leave it unattributed to me; that's just a standard header I put on all my scripts.)



Save the metric definition.   This is a screenshot of what your settings should look like on the definition:


Metric Def.png



Now create the report.   Run it against the Incident Metric [incident_metric] database view.   Make sure you add the following filter conditions:


  • Definition is Incident Touched
  • Value is Team Z (note that because Value is a text field, you'll have to type this in instead of selecting it)


If you don't want tickets that ultimately ended up in Team Z's queue (for example, only tickets that ended up in the queue of Team A, Team B, or etc.), then add a filter for:


  • Assignment group is not Team Z


If you want tickets that ONLY ended up in a queue of Team A, Team B, or etc. (that is, that didn't end up in some outside queue), add a filter such as:


  • Assignment group is Team A OR
    • Assignment Group is Team B OR
    • Assignment Group is Team C OR
    • ...


Personally, I would save this filter as a report source so that if you decide you want to filter it further by other criteria, you don't have to keep adding those filters first.   After that, you can add whatever other filters you want, such as created between, updated after, or whatever.



When that report is run, you will get a list of tickets without duplicates that were touched by Team Z at some point and, if you added the assignment group is not Team Z filter, ended up in some other team's queue.



If you just want a count and not a list of tickets, change your report time from List to Single Score.   (But I'd leave it as list at least initially to validate that you're getting back the records you're looking for.)   And as a side note, the time that the ticket was initially assigned to Team Z will be in the Start field of the Incident Metric view.



Hope this helps, and let me know if you have any trouble,


--Dennis R


View solution in original post

54 REPLIES 54

elbow
Giga Contributor

Hi Dennis,



Perfect - the metric is pulling in around 1000 instances a day (going on 3600 so far since it was created, and that includes a weekend!) Thank you so much for spending your time putting this complete package together for me!



I can now run a report which shows me any tickets that were assigned to ANY groups, at ANY stage of the ticket lifecycle (as opposed to just who it was assigned to at Resolution)



The script is a nice-to-have but I am meeting with some resistance from the administrators, which is completely expected. We may run it in a non-prod environment if it becomes something that is required, but for now the data since metric creation is fine.



I'm going to mark your response dated Aug 16, 2017 7:57 PM as the official Correct Answer, but obviously the script is also very useful.



A big shout out to @SachinNamjoshi too, who identified that this was likely to be the method required right from the get-go.



Kind regards,


Scott


Joey Diaz
Giga Contributor

Follow up question.   Let's say I want to be able to stack the results of the assignment group based on members of that assignment group.   The data I want to see is a ranking of Service Desk agents based on the number of tickets they handle.   I can then define some time frames like Week, Month, etc.  



Updated by doesn't seem to help because the value of the field is basically who last updated, which may be a member of a different group.  


So, it really depends on how you are hoping to view that metric. This script gives us a new metric instance whenever the assignment group is changed to a new assignment group that has never been assigned to it before.



If you were hoping to track any time an incident is assigned to a specific person, you may need to create a new metric that is similar to the one above, only instead of making a new row every time the assignment group is changed, you make a new row every time the assigned to is changed. I called this metric "touched by individual". However, this will only track any time the assigned to field is changed so you should consider if this fits your process enough to be useful.



Finally, if you wanted to track all of the incidents that team as even "touched" that is changed any fields that weren't the assigned to the incident you may need to track any time the incident is updated which is a third metric. I used the assignment group script, but my team's processes were too free-form for that to be reliable so I needed to make the updated by version to track how many incidents my team "touched".


I was thinking more about looking at the updated by information.   Sometimes tickets come through service desk and the agent fails (I know, right!) to assign it to themselves prior to sending it off.   If the script could look at users that have been listed in the Updated By data, then we could see Touched By Individual regardless of self-assignment.   Do you think that could work?


Unfortunately, Updated and Updated By are more complex metrics since they are primarily stored in the sys_audit table, NOT the Incident table.



I got my solution from Need help to create metric using the Updated by field. Ultimately, you will need to create a new Business Rule that will inform your Metric Definition. However, this is a completely different solution than the script Dennis created above which is why I didn't post the solution here directly.