An internal handoff between 1st and 2nd line can slip for hours before anyone notices. The customer-facing SLA still looks fine, right up until it doesn't, and by the time someone runs a report the delay has already happened. HaloITSM has just given that internal target the same early warning that SLAs have had for years.
HaloITSM 2.236, the 2026 Second Release, adds the ability to trigger notifications, webhooks or runbook events when an Operational Level Agreement (OLA) reaches a defined threshold. An OLA is the internal target attached to a Stage or Step within a Workflow, for example raising a ticket to 2nd line within four working hours, and it sits separately from the customer-facing SLA.
Administrators can set up to three thresholds per OLA, defined either as a percentage of time elapsed or as a number of working hours remaining. Trigger dates recalculate automatically if an OLA is paused and unpaused, so a ticket placed on hold does not set off a false alarm. Full detail is in the Halo release note.
Before this release, OLA performance was tracked but never surfaced proactively. The target hours, actual hours, target date and pass or fail flag were written to Halo's WorkflowHistory, FaultOLA and FaultOLADates tables, but the only way to see a breach was to run a report or query the database after the fact.
That meant internal slippage stayed invisible until it had already dragged down the customer-facing SLA, or until a customer complained about the knock-on delay. SLA breaches have had a proactive warning mechanism for years. This release brings OLAs up to the same standard, so a stalled handoff gets flagged while there is still time to act, not after the event.
Service desk agents Get a pop-up, email or push notification at or before an OLA threshold, instead of finding out about a missed internal target after it has already happened.
Team leaders Can be notified specifically when OLA breaches occur on tickets assigned to their team, giving them a chance to intervene before the target is actually missed.
IT management Get structured, queryable breach data, in the FaultOLA and FaultOLADates tables, and from version 2.248 onward, FaultsMetrics, to report on internal handoff performance without writing bespoke SQL.
Turning the mechanism on takes minutes: tick "Enable OLA events" in Configuration, Service Level Agreements, General Settings, then define up to three thresholds. Doing it well takes longer, because it depends on groundwork this feature does not do for you.
You need Workflows with properly defined Stages and Steps, and Work Hours calendars already in place, since the OLA timer is built against those. For each threshold, someone still has to create a separate notification record in Configuration, Notifications, Notifications and choose a delivery channel: an in-Halo pop-up, an email, or a webhook or runbook event for pushing the alert into external tooling. Three thresholds mean three separate notifications. There is no single rule that fires differently at each one.
No source confirms a licence or edition requirement for this feature, so check your Halo edition before assuming it is included.
A few details are worth knowing before you switch this on.
The richer notification variables, $-OLADESCRIPTION and $-OLATARGET, only arrived in version 2.238, two point releases after this feature launched in 2.236. On 2.236 or 2.237, your out-of-the-box notification text stays generic until you upgrade.
The OLA timer only counts down inside the Work Hours configured against it, so it pauses outside working hours and while a ticket is on hold. Halo's own documentation flags the "actual number of hours" field as having a misleading name for exactly this reason, worth knowing before anyone builds a dashboard on top of it.
Agents generally need to be subscribed to a notification to receive it, a detail that is easy to miss during setup. And detailed breach logging into FaultsMetrics only arrived in version 2.248, so the reporting side of this feature was built out gradually rather than shipping complete on day one.
As a Halo partner covering the UK and Israel, Hikon spends a lot of time in exactly this kind of configuration work: modelling Workflow Stages, Steps and Work Hours properly before switching on a feature like this, then building notification and webhook objects around thresholds that are actually useful rather than noisy. That groundwork, plus keeping agent notification subscriptions current, is usually where the real value sits, well beyond ticking the "Enable OLA events" box.
The full release detail is in the Halo release note. For more on the mechanics, see the Halo documentation. If you want a second opinion on whether your Workflows are ready for this, get in touch with Hikon.
Talk it through with the people who wrote it — a free 20-minute call, no pitch.
Let's talk →Book a free 20-minute call about your platform and your plans — no pitch, no obligation.
Start the conversation