SLA and working calendars
An SLA commitment in CloudFly Helpdesk is built from a policy, a working calendar and a ticket, plus three rules that decide whether it is met or breached.
An SLA is a promise about time, and a promise like that needs a clock that knows when it may run. This page explains the three pieces that make one, and the three rules that most often produce a result a reader did not expect.
Which controls to press lives on two other pages: Set an SLA policy for a team and Set working hours, shifts and leave days.
The three pieces
| Piece | What it states |
|---|---|
| SLA Policies | Which tickets are watched, how many hours the target is, which column counts as reached |
| Working Calendars | The hours during which the clock may run, and the leave periods cut out of them |
| The ticket | The thing being measured: its team, priority and current column decide which policy attaches |
A policy belongs to one team and points at one calendar. A ticket outside that team is invisible to the policy, however well the rest of it matches.
The clock counts business hours, not wall-clock hours
A policy target is expressed in business hours. Four target hours against a 09:00–17:00 calendar means four hours inside the shifts; nights and weekends do not count toward them.
The clock starts when the ticket came into existence, not when you saved the policy. Adding one today can therefore mark a handful of last week's tickets as late straight away.
Columns marked as excluded act as a pause button. Time the ticket spends sitting in one of them is added back onto the deadline, so "waiting on the customer" does not eat into the team's commitment.
Three rules that decide the outcome
An empty priority filter means "low only"
An empty priority filter reads as "applies to every ticket", but the matcher takes it the other way: a policy that names no priority matches only low priority tickets. The policy list prints that reading in its priority column.
To watch all four levels, create four policies and pick one level in each. This is the single most misread rule in the whole SLA feature.
A breach is permanent
Once a commitment turns into a breach it does not come back. Dragging the ticket into the reached column afterwards changes nothing, and the breach stays in the report.
The other direction does move: a commitment already marked as met is recalculated when the ticket leaves the reached column. With time still on the clock it returns to running; with the deadline already past it becomes a breach.
The arithmetic runs in UTC
The hours in a calendar's shifts are read as UTC. The timezone field on the calendar is stored and displayed, but the deadline calculation never reads it.
A team on duty 09:00–18:00 Vietnam time (UTC+7) has to enter the shift as 2
to 11. Entering 9 to 18 produces a calendar seven hours out, and the
symptom is deadlines landing in the middle of the night.
What a commitment looks like on a card
The SLA badge on a Kanban card prints in English in both console languages:
| Badge | Meaning |
|---|---|
4h left | Running, with that much time left according to the calendar |
| Overdue | Still running, deadline already passed, not yet re-evaluated |
| SLA breached | Recorded as a breach, and not reversible |
| SLA met | The ticket reached the target column in time |
One ticket can carry several badges, one per policy that matches it. Hover a badge to see which policy is speaking.
Read next
Roles and per-feature permissions
CloudFly Helpdesk grants access along two independent axes: the workspace role, administrator or agent, and the permission groups that decide who may write.
Contacts, channel identities and linked records
One human can occupy several contact records in CloudFly Helpdesk. How channel identities work, what linking asserts, and why a link is transitive.