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

willt2
Tera Contributor

This this worked perfectly for me. Do we know if there's an equivalent table for SCTASKs instead of INC?

2022....

This helped me today.

Thank You!

elbow
Giga Contributor

Thanks Sachin and Dennis for your answers so far.



Sachin - I currently don't have access to the Metrics module so I'm requesting that to begin with, and then I'll look at the possibility of creating a definition to help extract this data.



Dennis - I've had a crack at your suggestion too, but can't quite get it across the line as I'm not sure the [incident_metric] table has the fields I need to add the required Definitions. Also I get a row for every time an update was made on a record, whereas I really only want to see where a Work Note was added, and only one row per ticket.


I'd need to define something along the lines of Incident.Assignment Group.Parent.



Perhaps it'd help if I give a more specific description of what I am trying to do:



*****************************


I have several Assignment Groups that are subordinate to a parent group. So lets assume "Team Parent" is the high level group, with subordinates "Team A", "Team B", and "Team C".



I want to pull a list of all tickets that were eventually resolved by any of these subordinate groups, but that were also touched by a specific group "Team Z"



So a result might be (Incidents resolved/closed = Last Month)


Team Parent = 300


Team A = 50 (and 40 were assigned to Team Z at some point during the ticket lifecycle)


Team B = 150 (and 120 were assigned to Team Z at some point during the ticket lifecycle)


Team C = 200 (and 100 were assigned to Team Z at some point during the ticket lifecycle)


*****************************



Maybe I need to use another table, such as [task_metric] but of course I will then need to use more definitions to reduce the noise, and restrict results to class = Incident.



Regards,
Scott


So let me get this straight, when you say that a ticket is "touched by" a team, what exactly do you mean?   I was assuming that you meant that it was assigned to that team at some point.   But do you mean that the team entered any work note?



For example, if I'm on Team Z, and I enter a work note for INC0012345, are you considering INC0012345 "touched by" Team Z, even if it was never assigned to Team Z?   If so, that will be moderately difficult, because although I might be a member of Team Z, I could also be a member of Team X and Team Y.   ServiceNow doesn't have any good way of knowing that when I touch a ticket that I'm doing so on behalf of Team Z and not Team X or Team Y.   (Unless you want to consider the ticket to be considered touched by all three teams when I enter a comment, but I'm not sure that's what you intend to report on.)



Personally, I'd drop the idea of using the work notes, because you can get into a real rabbit hole of a situation trying to query those.   If you really want to, they're stored in the sys_journal_field table, with [element] being set to the work note type (you'll probably be looking for "work_notes") and [element_id] being set to the sys_id of the task.   You'd have to write a script that iterates over all incidents (hopefully limiting the resultset by date or something), then for each incident, query the sys_journal_field table looking for entries where the element_id is in the list of sys_ids from your first query and the sys_created_by is one of the sys_user user_name values for the users in group Team Z or any of its descendants. Then you'd need some way of making that information available for reporting, which would probably involve a Performance Analytics table or maybe something fancy with metrics.



I'm kind of slammed at work today, so I doubt I'll be able to revisit this after this post, but I'll cogitate on it a little further.   I can probably script up something to give you the table you posted above using a custom metric, but I'll have to think about what would be involved in precisely defining the info.


Hi Scott,



We have implemented similar functionality to report on tickets ( incidents, catalog tasks) touched by SD.


We created field on incident and catalog task and created business rule to update this field with comma separated values for different SD groups.



Also, we created report on these tables to show data as per your requirement on performance analytics dashboard.


These reports is calling script include which parses data for each parent and child SD group. We have interactive filters on our PA dashboards based on parent and child SD resolver groups.



Regards,


Sachin