Service-Level Agreements

A service-level agreement (SLA) policy sets two targets for a ticket: how long until a first response, and how long until resolution. This page covers how each clock runs, how to create a policy, and what pausing does.

Read a target as an internal workflow timer. It drives the warning and breach indicators an Agent sees on the queue. It is not a support commitment to a requester or a customer, and configuring one creates no obligation on Finlay.works.

"First response" means the requester heard back. Only a Public update satisfies the first-response target. An Internal note does not: a private triage note leaves the countdown running, because the requester still has not been told anything.

So the figure measures replies to requesters, not internal pick-up. A ticket an agent has read, triaged, and annotated privately still holds an open first-response target until someone posts something the requester can read.

Each target chooses its own time mode

A policy does not have one clock. First response and resolution each carry their own time mode, and they can differ on the same policy.

When the two targets use different modes the SLA Policies list shows the policy's TIME MODE as Mixed target modes rather than naming one.

Business-hours mode requires a calendar. See Business calendars for creating one.

The calendar version is snapshotted when the policy is saved. A policy binds the calendar as it was at save time, not a live reference. Editing the calendar afterwards creates a new version and does not retroactively change policies bound to an earlier one, nor tickets already running against it. To move a policy onto a revised calendar, open the policy and save it again.

Before you start

• You need SystemAdmin access and step-up verification.
• The owning department must be enabled.
• Agree the first-response target, the resolution target, or both, in whole hours.
• If either target should follow working hours, create the business calendar first.

Create an SLA policy

1. Open SLA Policies. The list shows active, incomplete, and unused policies.
2. Select Add policy.
3. Choose the owning department.
4. Enter the policy name and description.
5. Enter the First response target (hours), the Resolution target (hours), or both. At least one is required. Leave the other empty if you do not set it.
6. For each target you set, choose its time mode:
   • 24/7 wall-clock needs nothing further.
   • Business hours calendar also needs a calendar chosen in the matching First response calendar or Resolution calendar control.
7. Set the warning threshold (%) for each target if the default does not suit. This is the share of the target still remaining when the queue starts showing the ticket as due soon. Each target has its own threshold and both default to 25.
8. Set Effective from and, if the policy should stop being selected on a date, Effective until. The service rejects an end date before the start date.
9. Select Make this policy active for new tickets in [department] only when the targets are agreed.
10. Select Create policy once. The policy appears in the list.

How a ticket gets its policy

A new ticket takes its SLA from its service where the service names one, and from its department otherwise. In both cases the policy must be owned by the ticket's department, be active, and have an effectivity window covering the moment the ticket was created.

Where more than one policy qualifies, selection is deterministic: the newest effective-from date wins, then the most recently created, then a stable tie-break. You are not required to keep exactly one active policy per department, though doing so still makes the estate easier to reason about.

A ticket keeps the SLA instance it was given when it was created. Changing, deactivating, or deleting a policy does not change tickets that already hold one.

A service default takes precedence

Where the ticket names a service, that service's Default SLA policy (optional) is used instead of the department selection. The product checks, in order:

1. Does the ticket name a service, and is that service active and in the ticket's department?
2. Does that service name a Default SLA policy?
3. Is that policy active, and is the ticket's creation time inside its effective dates?

If all three hold, the service's policy is applied. If any of them fails, the product falls back to the department selection without saying so. There is no warning and nothing on the ticket records that a fallback happened.

That matters when a service default is deactivated or its effective window closes: tickets keep being created, they keep getting an SLA, and the targets quietly change to whatever the department rule returns. If timings shift unexpectedly on one service, check that its named policy is still active and in date before looking anywhere else.

A ticket with no service always uses the department selection.

See Services and the Service Catalog.

Delete an SLA policy

Deletion is a two-step action: you arm it, then confirm it.

1. Remove or replace the policy on every service that uses it as its default.
2. Open the policy in SLA Policies.
3. Arm the delete control, then confirm.

Step 1 is required, not tidy-up. The database blocks the delete while any service still names the policy as its default, and the failure surfaces as a raw database error rather than a message naming the service. Clear every service default first.

Tickets that already hold an instance of the policy still need review; deleting the policy does not clear them.

Pause the clock

While a ticket sits in a status marked Pauses SLA timer, BareBones Ticketing holds the clock. Paused time is credited consistently: it is excluded from the remaining time shown on the ticket, from the warning decision, and from the breach decision.

How the credit is applied depends on the target's time mode:

• 24/7 wall-clock — accumulated paused time is subtracted from the current time when the target is assessed, including any pause still in progress. The due date itself is written once at ticket creation and is never moved.
• Business hours calendar — while the ticket is paused the assessment freezes at the moment the pause began, and when the ticket resumes the due date is moved: the business-time equivalent of the pause is added to it.

So the two modes reach the same outcome by different routes, and only the business-hours mode rewrites the stored due date. Either way, a ticket that was paused is not pushed into breach by time spent paused, and the warning and breach indicators agree.

This behaviour changed in a product update. Earlier revisions accumulated paused time but never applied it to the breach comparison, so a paused ticket could show as on track in the queue while the background worker recorded a breach. The behaviour described above is what the current product does; on an older build, expect the earlier behaviour.

Set Pauses SLA timer on the status, not on the policy. See Workflows and statuses.

If it does not work

• The policy does not appear on a service. The policy belongs to a different department than the service, or it is not active.
• A ticket has no SLA. Neither its service's default nor its department had a policy that was active and within its effectivity window when the ticket was created.
• A service's tickets are on the wrong targets. Its Default SLA policy has fallen through to the department selection. Check that the service is active and in the same department as the ticket, and that the named policy is active and in date. The fallback is silent.
• Timing looks wrong across a weekend. Check the target's time mode. On 24/7 wall-clock the weekend counts. On business hours it should not, so confirm the bound calendar actually marks those days non-working, and that the policy was saved against the calendar version you expect.
• A revised calendar did not change existing timings. Expected. The calendar version is snapshotted at policy save, and tickets keep the instance they were created with. Save the policy again to bind the newer version, for tickets created from then on.
• A ticket shows the wrong TIME MODE. The list column reads Mixed target modes whenever first response and resolution differ. Open the policy to see which target uses which.
• Two policies could both apply. Selection is deterministic — newest effective-from wins. Check the effectivity dates rather than assuming the result is arbitrary.

Related pages

• Business calendars
• Workflows and statuses
• Services and the Service Catalog
• Limits and scope
• Glossary