Halo Service Desk Guides
Documentation to assist with the setup and configuration of the Halo Service Desk platform
Operational-Level Agreements (OLAs) on Workflows
For The Guide on Workflows click Here
Operational-Level Agreements are, at their very base, target times for certain parts of a Workflow, whether that be the Stages or individual Steps.
The main configuration for these will be on a per-Workflow level, with the magic happening in the "OLAs" tab [Formerly The "Targets" Tab].
The workflow we will be looking at for this guide is this "Cover-all Workflow". This workflow acts as an all-in-one (rather broad) ticket processing flow, from start to finish;
The Concept
Our Workflow above, as you can see from the Details tab, has 4 'Stages' associated with it. These are a higher level grouping for organising your various Steps in a Workflow. You can see which Steps belong to which Stages on each box on the Flow Chart tab.
Now, as you can see, a Stage can be placed anywhere throughout the workflow, and doesn't necessarily have to be in logical order, as we have Stage 4 coming straight from Stage 1 with our "Development Task" Step. However, it is advised that you keep these ordered, at least numerically, when using Targets.
Targets can be configured to regulate the time it takes to go from one Stage to another, or alternatively; one Step to another. These would act in a somewhat similar way to Service Level Agreements, in the way that they are guides for how quickly (or slowly) a process is expected to be completed. The only consequences associated with missing these Targets would be those that you configure yourself (using database lookups, for now). As insinuated, the Target data is only stored in the Database at the moment, so if you would like any functions to run off of it, a database lookup will need to be used to populate fields for such automations. The main use for this data would be for reporting purposes, with these four different bits of information being stored in the WorkflowHistory database table:
- Target number of hours
- Actual number of hours
- Target date
- Was the target met
As for the targets configured above, seen in the OLA's tab, the two marked in blue are based on Stages, whereas those marked in red are based on Steps.
A basic use case for these is seen here, with a simple-to-interpret Target Name for usability. These metrics would already be able to be calculated via reporting beforehand, however the SQL would be rather intricate if it needed constructing manually, involving all sorts of joins and subqueries to Actions or Audit. Now, with these Targets, there will be a solid metric that you can look for in the database for exactly the data you're after.
It is worth noting at this point that the Target times for each ticket will only tick down inside the Workdays configured inside that ticket's SLA. This also means that On-Hold time will not deduct from the target time. The above metric for "Actual number of hours" will follow the above behaviour, contrary to it's misleading name.
Configuring one for yourself
To add to the convenience of this functionality, the construction of these Workflow OLA's only involves a few fields!
First, you will want to take a look at your own Workflow's Flow Chart and Details and make sure that you have appropriate Stages associated with each Step, should you be wanting to track that data. If not, Steps alone will suffice.
Then, all you need to do is head to the OLA's tab and click the 'Add' button. That will open up the following interface, in which you can configure the OLA.
The OLA will require the following:
Now we have a Workflow with trackable Targets! Let's take a look at how to report on them.
Reporting on OLAs
So, here's the fun part; the SQL you need to find all this new information...
The main data we are looking for is stored in the WorkflowHistory table. Here, the details of any movement between Workflow Steps is recorded, along with the appropriate Stage changes, should there be any:
- WHID: This is purely an ID field, and is of no importance here, other than ordering the data.
- WHFaultID: This is the Ticket ID that this data is related to.
- WHMovedTo: This is the Workflow Step that was moved to at this change.
- WHMovedFrom: This is the Workflow Step that was moved from at this change.
- WHFlowID: This is the Workflow ID in which these movements are taking place.
- WHMoveDate: This is the date and time at which this move took place.
- WHMovedFromStage: This is the Workflow Stage that was moved from at this change.
- WHMovedToStage: This is the Workflow Stage that was moved to at this change.
- WHTargetHours: This is the expected time for this movement to take place, according to the targets set up on the Workflow.
NB: If two or more targets are involved with the one movement, then the Stage Target will take priority and be stored in the database. - WHActualHours: This is how much time has been taken on that specific movement. (This ignores time On-Hold and Out-of-Hours).
- WHTargetMet: A true or false value to determine whether or not the movement has met the Target time.
- WHTargetDate: This will be the date and time by which this Target was expected to be met for this movement.
In order to find this data for an individual ticket, the join would be:
FROM Faults
JOIN WorkflowHistory ON Faults.FaultID = WorkflowHistory.WHFaultID
This would show any movements for that ticket.
You would need to add additional filters if you wanted to specify a certain Target. The information for Targets is found in WorkflowTarget, where the Target's name and Steps/Stages are defined, along with the expected times and units. This would require a subquery as below.
You can then use WHERE clauses to specify a certain Target being met. For my example above, if I were to want the Time to Triage target's information, we would need the 'Target Name' to be "Time to Triage" and the 'Moved To Stage' to be the same as the relevant Target's:
SELECT
FaultID AS [Ticket ID],
Symptom AS [Summary],
WHActualHours AS [Time to Triage (h)],
WHTargetMet AS [Triage Target Met?]
FROM Faults
JOIN WorkflowHistory ON Faults.FaultID = WorkflowHistory.WHFaultID /*This is to get access to the movement data.*/
WHERE
FaultID = 2171 /*This is to specify the ticket we want, your ID will, most likely, be different.*/
AND WHMovedToStage = (SELECT WTEndFSID FROM WorkflowTarget WHERE WTName = 'Time to Triage') /*This is specifying that we want the Triage target.*/
Popular Guides
- Asset Import - CSV/XLS/Spreadsheet Method
- Call Management in Halo
- Creating a New Application for API Connections
- Creating Agents and Editing Agent Details
- Departments, Teams and Roles
- Halo Integrator
- Importing Data
- Multiple New Portals with different branding for one customer [Hosted]
- NHServer Deprecation User Guide
- Organisation Basics
- Organising Teams of Agents
- Step-by-Step Configuration Walk Through
- Suppliers