SLAs

Service Level Agreements (SLAs) put response and resolution targets on tickets, warn you before a target is missed, and record whether each target was met.

SLAs are entirely optional. Until you assign one, nothing about ticketing changes - no targets are set, no colours appear and no notifications are sent. You can also switch them off for a single client, a single priority, or a single ticket.

• ITFlow 26.08 or newer (database version 2.5.0)
• The Ticketing module enabled
• The ticket_sla.php cron script scheduled - see Cron. Without it, targets are still calculated and displayed, but you get no warnings, no breach alerts and no row colouring
• mail_queue.php running, if you want SLA alerts by e-mail as well as in-app

An SLA plan is a named pair of targets, for example Gold with a 30 minute response and 240 minute resolution. Plans are reusable.

An assignment connects a plan to a priority. Assignments exist at two levels:

• Global defaults - apply to every client, set in Admin > SLAs
• Client overrides - apply to one client, set on that client

When a ticket is created, ITFlow looks for an assignment matching the ticket's client and priority. A client override wins if one exists, otherwise the global default applies. If neither exists, the ticket simply has no SLA.

Targets are calculated once, when the ticket is created, and stored on the ticket. They are counted in business minutes, so only time inside your configured business hours is consumed.

Navigate to Admin > SLAs and select New SLA.

Most MSPs need two or three plans. A common starting point:

• Priority - 30 minute response, 240 minute resolution
• Standard - 120 minute response, 480 minute resolution
• Best effort - 480 minute response, no resolution target

Plans can be archived later rather than deleted, which preserves the history on tickets that used them.

On the same page, fill in Business Hours & Notifications.

These settings apply to the whole install and use your ITFlow timezone.

Changing business hours recalculates targets on all open tickets that have an SLA, because the underlying maths has changed. The number of tickets updated is shown after saving.

Under SLA Assignments, choose a plan for each priority - Low, Medium, High and Urgent - then select Save Defaults.

Leave a priority set to None if it should not carry an SLA at all. Many MSPs set None for Low so that long-running, low-urgency work is never counted as breached.

Saving defaults re-evaluates every open ticket against the new assignments.

Client overrides live on the client, not in the admin area. Edit a client, open the Notes tab and use the Ticket SLAs selectors.

Each priority offers three choices:

• Default - follow the global default for that priority
• None - this client gets no SLA at that priority, even if a global default exists
• A named plan - this client uses that plan at that priority

The same selectors appear when creating a client. They are only shown once at least one active SLA plan exists.

Saving a change re-evaluates that client's open tickets. Saving a client with the SLA selectors untouched changes nothing.

Targets count business minutes from the moment the ticket was created. Time outside business hours does not count.

With business hours of 09:00-17:00 Monday to Friday and a 60 minute response target:

If no usable business calendar is configured - no days selected, no hours set, or an end time earlier than the start - the clock runs 24×7.

Starts when the ticket is created and stops at the first response. A first response is recorded by:

• A public reply to the ticket
• Resolving the ticket, if no reply was made first
• Merging the ticket

Internal notes do not count as a response. This applies to bulk replies as well as single replies.

Starts when the ticket is created and stops when the ticket is resolved, or closed without being resolved.

Reopening a resolved ticket puts it back on the resolution clock against its original due date. There is no pause or extension yet.

The ticket view shows the SLA name alongside the priority, and the two target dates under the ticket details. A green tick means the target was met, a red warning triangle means it was missed.

Selecting the SLA name opens a modal where you can pin the ticket to a different plan, or to None to remove its targets entirely. This needs support module write access, and is unavailable once the ticket is closed. Changing the SLA recalculates both targets from the ticket's creation time.

• Yellow - a target is approaching, at the warning percentage you configured
• Red - a target has been missed

Closed tickets are never coloured.

Once the cron script is scheduled, each ticket generates at most one warning and one breach alert per clock. Alerts are sent in-app and by e-mail to the SLA notification address and the assigned agent - if these are the same person, only one e-mail is sent.

Changing a ticket's priority or client re-runs the assignment lookup and recalculates both targets from the ticket's creation time. This also clears a per-ticket SLA you pinned manually.

This matters for a common pattern: an outage raised as Urgent, then downgraded to Low and left open for a week of monitoring. After the downgrade, the resolution target is measured from when the outage started, so it may be missed almost immediately. Three ways to handle it:

• Resolve the outage ticket when the outage ends and monitor on a separate ticket - the cleanest option, and the most accurate reporting
• Downgrade the priority first, then pin the ticket's SLA to None - order matters, because changing priority afterwards clears the pin
• Assign None to Low, so downgrading to Low drops the SLA automatically

Status-based pausing is planned and will make this unnecessary.

Editing a plan's targets recalculates open tickets using that plan. Changing business hours recalculates all open tickets with an SLA. Closed and archived tickets are never touched.

Archiving a plan leaves existing tickets with the targets they already have, but any assignment pointing at it stops applying, so new tickets get no SLA. Restore the plan to undo this.

Tickets raised through the client portal, the e-mail parser, the API and recurring tickets all get targets in the same way.

These are planned for a future release:

• Pausing the resolution clock on statuses such as Waiting on client
• SLA reporting and filtering tickets by SLA state
• SLA colouring on the kanban board