Business Calendars

A business calendar describes when your organisation is working. An SLA policy target set to Business hours calendar counts only the time inside the bound calendar's working hours, so nights, weekends, and closures do not consume the target.

A calendar does nothing on its own. It has an effect only once an SLA policy target binds to it. See Service-level agreements.

Calendars are defined once for the whole installation, not per department. Any department's SLA policy can bind any active calendar, so name them for the working pattern they describe rather than for a single team.

One behaviour to know before you bind one: on a business-hours target, pausing a ticket moves its due date. When the ticket resumes, the business-time equivalent of the pause is added to the stored due date. On a 24/7 target the due date never moves. See Pause the clock.

Before you start

You need SystemAdmin access and step-up verification.
Agree the working week, the daily start and end times, and the timezone those times are expressed in.
Collect the closure dates you already know about for the period the calendar covers.

What a calendar contains

A calendar has three layers. Later layers override earlier ones.

The calendar itself — name, timezone, description, and the period it is effective for.
Weekly intervals — the normal working week: which days are working days and the start and end time on each.
Date exceptions — named single dates that differ from the weekly pattern, either closing a normally-working day or opening a normally-closed one.

Create a calendar

Open Business Calendars and select New calendar.
Enter the Name. This is what appears in the SLA policy calendar selector, so name it for the working pattern rather than the department.
Choose the Timezone. Every start and end time in the calendar is interpreted in this zone. The list shows IANA zone names with a sample offset, for example Europe/London (sample UTC+01:00).
Enter a Description explaining who the pattern is for.
Set Effective from and, where the pattern is known to end, Effective through.
Under Weekly intervals, set the working Start and End time for each of Mon to Sun that is a working day. Leave a day without an interval to make it non-working.
Add any known Date exceptions — see below.
Leave Active set if the calendar should be selectable by SLA policies.
Select Save calendar.

Choose the timezone deliberately. The calendar's own timezone governs its working hours, not the reader's display timezone and not the tenant's. A calendar in UTC and one in America/Detroit with the same 09:00–17:00 pattern describe different real hours.

Add a date exception

Use exceptions for public holidays, shutdowns, and one-off working days.

Add closed day — a date that would normally be working but is not.
Add working day — a date that would normally be non-working but is.

Each exception carries a Date, a Name for the reason, a Posture of Closed or Working hours, and a Start and End time. A Working hours exception uses its own start and end rather than the weekly pattern's, so it can also express a short day.

Give every exception a name. The name is what makes a calendar reviewable a year later.

Check the calendar before you rely on it

The Calculation preview on the calendar shows, for a start moment and a duration, when this calendar says the target is due.

Enter a Start date and Start time.
Enter Duration minutes — the target you intend to set, in minutes.
Select Calculate.

Test at least the awkward cases: a start late on the last working day of the week, a start during a closure, and a duration long enough to span a weekend. A calendar that looks right in the weekly grid can still be wrong at the edges.

Versioning

Editing a calendar creates a new version. The list shows each calendar's current VERSION alongside its NAME, ZONE, and STATUS.

Versions exist because SLA policies snapshot the calendar version they were saved against. That means:

Editing a calendar does not change SLA policies already bound to an earlier version, and does not change tickets already running.
To move a policy onto the revised calendar, open the policy and save it again. It picks up the current version at that point.
Tickets created before the policy was re-saved keep the timings they were given.

This is deliberate: a correction to next year's holidays should not silently re-time work already in flight. It also means a calendar edit alone is never enough to change behaviour — there is always a policy save to follow.

Deactivate a calendar

Deactivate takes the calendar out of the selector for new policy bindings. It does not detach policies already bound to it, and does not change tickets in flight.

Before deactivating, check which SLA policies bind the calendar and decide what they should use instead. Deactivating first leaves those policies pointing at a calendar nobody can select again.

If it does not work

The calendar is not offered on an SLA policy. It is inactive, or its effectivity period does not cover the moment you are saving the policy. Check Active and the effective dates.
Timings did not change after editing the calendar. Expected. The policy holds a snapshot of the earlier version. Re-save the policy.
Times are out by a fixed number of hours. The calendar's timezone is not the one you meant. The times you entered are interpreted in the calendar's zone, not yours.
A holiday was still counted as working time. The exception was added after the policy was saved, so the bound snapshot predates it. Re-save the policy.
A ticket ignores the calendar entirely. The target is set to 24/7 wall-clock, not Business hours calendar. Time mode is per target, so check both first response and resolution.