Howdy y’all,
I’m a fire analyst, not an IT guy, so bear with me while I try to make heads or tails of this data mess. I’ve got a metrics table (incident_metric) that tracks who’s working on incidents, and two SLA tables (incident_sla and u_all_task_sla) that’s got timestamps and some long 16-digit IDs—but no names. Below is incident 61:
Here’s what I know:
- We use IT’s ticket system to keep up with all kinds of things—hydrants, computers, and whatever else needs fixin’.
Susan was assigned to a ticket, then passed it over to Jane.
When Susan assigned it to Jane, the first resolution SLA closed.
Then Jane resolved the incident, triggering a second resolution SLA.
The problem is, my SLA table doesn’t have people—just timestamps and those long IDs (called sla_sys_id). So how in the world do I connect these two tables to see who was responsible for each SLA event?
I appreciate any wisdom y’all can share. I may know how to put out fires, but this data is burning me up!
Thanks in advance!
SLA records always capture the timestamp, not the person assigned to the SLA.
You can refer to the out-of-the-box (OOTB) database view to get a better understanding of how it works.
I don’t have access to the "out-of-the-box (OOTB) database view" or the "SLA breakdown plugin" since I ain’t in IT. But I do have access to the "API Explorer," so I pull the data using that and the "SN Utils" extension. From what I can tell, the duplicates mostly happen with the response SLA.
@AndersBGSWell, I went ahead and used that extension and found something called the "SLA Timeline." When I click on an SLA inside it, it pulls up a start, stop, pause, and cancel time—but I can only look at one SLA at a time. If I post the more info, reckon you could help me out?
@Dr Atul G- LNG
From what I’ve seen in the work notes for other tickets than 61, the person assigned ain’t always the one changing the state of the ticket. That’s why I figured maybe another table, like incident metrics, might be tell me who is updating when an SLA open and closes.
As for the SLA definitions, they all seem tied to priority and state changes. (Earlier, I got Priority and urgency mixed up in my example—turns out the Priority 3 SLAs were actually Priority 4, and the Priority 4 SLAs were also Priority 5.)
The Priority 4 SLA response stop
The Priority 4 SLA response cancel
The Priority 5 SLA response stop:
The Priority 5 SLA response cancel:
Looking at the time line I found that the first response SLA (when Susan was assigned) was canceled. The ticket was the updated by Jeff (someone other than Susan) and she was assigned the ticket.
Then I found that the second response SLA (closes when it was assigned to Susan who then assigned it to Jane immediately). This was not Susan who changed it but Bob.
Then I found that the third response SLA closes when Jane changes the state on the ticket, but I don't see what state that is:
