SLA to track time between New Inbound Email & time to generate Incident Number

Chisholms1
Tera Contributor

Has anyone had a requirement to configure a Service Level Agreement (SLA) to track the time from when an inbound email is received (when a CALL record is generated) to when an Incident Number is created?


--> Inbound email comes in => SLA starts
--> Inbound script creates an Incident (perhaps adding a custom field on the inbound email table, saying Incident created or not)
--> If Incident Number is created, then SLA Stops

 

Appreciate any feedback or help with this!

2 REPLIES 2

Robbie
Kilo Patron
Kilo Patron

Hi @Chisholms1,

 

Interesting question. Whilst I've never seen or heard of this requirement before, I would steer you toward leveraging a Metric rather than SLA.

 

Typically SLA's are configured around 'task' tables.

The data you're after would be contained on the sys_email table which does not extend task. Whilst you could code and configure around this, by using a metirc on the sys_email table, thinking out loud high level, when the email is received the record would be created in the sys_email table. Then, to measure when the appropriate ticket is created, the target field within the sys_email table would be populated and the state field would be updated to 'processed'.

 

One thing to consider is, that not emails will be processed or create a record so we may not want to start a metric for every email. Alternatively, after a record has been created via an email such as an incident for example, you could circle back and lookup the corresponding sys_email record that related and triggered the process and grab that created time to store and measure against.

 

To help others (or for me to help you more directly), please mark this response correct by clicking on Accept as Solution and/or Kudos.

 

Thanks, Robbie

Mark Manders
Mega Patron

SLA's can be configured to run on the task table. Since emails aren't a task record, that won't work. Question is: why would you want to do this? What is the use case behind it? An email comes in, the inbound action runs and the incident is created. It's a matter of seconds or maybe minutes if the instance is busy. 

What kind of SLA (the signed document) contains this level of reporting? 

 

But if it is a hard requirement (when it's agreed, it's agreed and needs to be reported on) and you can't manage it back anymore, you have a problem. The solution could be to create a field on the incident form (not the email form) and within the inbound action or inbound flow, define a variable for the email creation data/time and have that filled on the incident. You then create an SLA on insert of the incident with a retroactive start on your new date/time field. and you're done...

 

But: if the stop condition of an SLA definition is already true on creation of the SLA, the SLA record doesn't get created. So that's a problem. 

I never tried it, but maybe this could work: create a flow on insert of the incident (after you have created the new field and have it filled with the email creation time). From their use the 'Create Record' step to create a new record on the task_sla table. Fill the fields you need (start time is incident.new_field date/time, stop time = incident.sys_created_on date/time). Create an SLA definition to define the breach time and set the stage to completed. You may need to do some calculation in there as well, but at least you have the task_sla records to include in your reporting.

 

THE ABSOLUTE MOST IMPORTANT THING ON THIS REQUIREMENT: let them show you the signed agreement where this is something you should create, because if there is no obligation to have this to report on, don't even start on it.


Please mark any helpful or correct solutions as such. That helps others find their solutions.
Mark