The SLA system makes use of 'Traffic Lights'. Consider traffic lights to be similar to the 'status' of a form, but one which is only ever controlled automatically.
An SLA is used for counting passing time and assisting in automatic changes based on those times.
For example, a newly submitted ticket could have a traffic light status of 'Within SLA' but after 5 hours, it's needed for the traffic light to change to 'Out of SLA'.
How SLAs are seen
SLAs will always show at the top of each ticket submission:
The corresponding colour of each SLA will highlight the far left of each ticket row to denote what it's currently in:
Optionally a traffic light column can be added to appear in the ticket list area, where the associated label will appear:
1. Creating Traffic Lights
Your Intranet management team can brainstorm what traffic lights would be required to best fit the stages of your form, as well as how long a ticket should remain in each traffic light before it moves to the next.
Field condition sets will need to have been created ahead of time to define what changes can be tied to traffic lights and prompt them to change too.
Once ready to create them head to Admin > InfoCapture > (your project) > SLA
Under the traffic lights tab, click the 'Add' button and choose a label and a colour.
A simple example is to create one for within, and one out of, SLA:
2. Creating SLA Rules
Next head to the 'SLA rules' tab.
Here you will use your chosen field condition sets to determine when a traffic light change should occur.
In the simplest example shown below once a ticket is submitted and enters 'Requested' status, it is labelled 'Within SLA'.
You'll also notice the 'type of time count' column has two options: From latest status change, or 'by stopwatch timer'.
The time interval is set to 0 as the traffic light change is desired as soon as that condition is met.
Until 8 hours pass at which point it will change to 'Outside SLA'.
The 8 hours is custom curated, so really this time period can be whatever you need it to be for your forms.
3. Add a timer action per status
A timer will run in the background for the benefit of SLAs.
The way the system is told how to run the timer is in the 'Statuses' tab:
In each status, the timer can be started, paused, and stopped.
Generally, you would want a timer to begin when a form is submitted and for it to stop once the form has reached a closed status.
As you can see from the 'rejected' or 'ordered' line above, sometimes it can be useful to pause the timer, however, this totally depends on the requirements of your form's use case.
4. Define working hours
In the 'worktime' tab define which hours of the day the timer should run, which can again be custom configured to fit the specifications of a form:
Tick the days you want to be active and then use the dropdown to set a start and end time.
These are the only periods that the timer will be active and contribute to the changes in SLA.
This is really beneficial to ensure timers aren't running when it's the weekend or non-working hours!
5. Test
Submit tickets in your form that meet certain conditions used in your SLAs.
To speed up the testing process, enter smaller time periods e.g. 5, 10 minutes for each change, rather than your intended figure if this is e.g. 350 hours.
Watch over the tickets and check that they move through each traffic light when appropriate and that the label updates as expected.
As SLAs rely on the background task running, there could be delays in the label updating or being applied at all.
So, when testing SLAs make sure to give a few minutes for the system to apply the rules.
Its also important to note, if an SLA is changed once saved in an established form with tickets already in it e.g. the number of hours in the time interval, new tickets submitted will follow the updated rule and change after the new time but past tickets in the form will need some kind of interaction to rectify (where applicable) e.g. editing and saving it, status change etc to update the SLA.
Outside this past tickets submitted before the changes should update when the background task runs (which is every day at 5 AM)
Therefore if you make changes to SLA timeframes it is best to wait at least 24 hours to check past tickets update as expected and if they do not after this period, let us know in a support ticket.
More advanced SLAs
More complexity can be added than just within or outside an SLA.
Take a look at this example, from an InfoCapture project for submitting IT support tickets:
If the status of a ticket has been changed to 'Submitted', 'Awaiting Confirmation', or' Closed', the traffic light will be immediately changed to those seen in the 'Traffic light' column.
If no change has taken place after 16 hours, a ticket in 'Submitted' will have its traffic light change to 'Resolution time breached'.
Look further down, to the 'xxxx Problem submitted' lines. Here a field condition has been used to capture certain entries in form fields to create a tier of responses:
This setup means that the different urgencies submitted by users will behave uniquely based on the times entered for them to determine when they move to 'Resolution time breached'.
The other statuses tickets can move through have also been covered by the 'xxxx Problem' conditions:
This ensures once they move out of 'Submitted' a new slightly longer SLA change is implemented.
This project has also defined that any ticket submitted as a 'Question' or 'Request' in a 'Type' form field will not be involved in the SLAs.
It's not appropriate for this company's processes for these types to require an SLA, therefore it's been given its own traffic light to denote this 'No SLA' which it will stay in until moved to 'Awaiting confirmation' or 'Closed' status.
Notifications
You may also wish to send notifications based on your SLA.
This is useful to ensure users who need to interact with tickets ahead of breaches can do so or those who need to be involved in escalation once a ticket has been breached are made aware.
To do so, perform the following steps:
- Create a field condition that specifies Traffic light is SLA breached
- Create a trigger with the following rules
a) Condition WAS NOT: Traffic light is SLA breached
b) Condition IS NOW: Traffic light is SLA breached - Create a notification that uses that trigger.
Key Facts
- The background task processes traffic lights, and then automatic changes.
The rules trying to be followed are traffic light-> automatic change ->traffic light which would have to be spread out between two runs of the background task. - The background task only checks traffic lights for an issue if a timer has expired.
- A timer is only set if a real user saves an issue or if the current SLA traffic light has another traffic light following it.
Recommended next article:
Workflow
