> For the complete documentation index, see [llms.txt](https://docs.siit.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.siit.io/guides/workspace/business-calendars.md).
# Set up business calendars
Create Business Calendars with a timezone and working hours, attach them to SLA Rules and to admins per inbox, and handle requests that arrive outside working hours
### What are Business Calendars?
Business Calendars let you define working schedules and attach them to two things: SLA Rules (to control when SLA clocks run) and admins (to control who requests get routed to based on availability).
You can create as many calendars as your team needs — one per region, location, or shift pattern.
{% hint style="info" %}
Business Calendars feature is available on the Pro Plan.
{% endhint %}
**For existing customers — what's changing for you**
Short answer: nothing breaks, nothing requires action.
Your existing SLA behavior carries over automatically. Here's exactly what happens:
* Your previous Office Hours schedule has been migrated into a Business Calendar called ***Office Hours*** visible in ***Settings → Business Calendars.***
* All your existing ***SLA Rules*** reference this calendar by default. SLA timing works exactly as it did before.
* For every distinct SLA configuration you had set up across your services, a corresponding SLA Rule has been created automatically. No manual migration required.
Your SLAs keep running. Your routing keeps working. The only difference is that your schedule now lives in a named calendar you can see, edit, and extend — alongside any new calendars you create for other teams or locations.
When you're ready, you can create additional calendars and attach them to new SLA Rules. But that's optional — there's no deadline and no forced change to how you operate today.
**Getting started**
If you're setting up Business Calendars for the first time (or extending your existing setup), follow these steps.
**Step 1 — Create your calendars**
Go to Settings → Business Calendars and click New Calendar.
For each calendar:
* Give it a clear name (e.g. "EU Support — CET", "US East — ET", "24/7 On-call")
* Select the timezone — all hours are interpreted relative to this
* Set working days and open/close times for each weekday
Create one calendar per distinct schedule your team runs. If everyone works the same hours, one calendar is enough.
**Step 2 — Attach calendars to SLA Rules**
Go to Settings → SLA Rules. For each rule, select the Business Calendar that should govern when the SLA clock runs.
If you have teams in different time zones, create a rule per team and attach the relevant calendar to each one.
**Step 3 — Assign calendars to admins per inbox**
In each inbox's settings, assign a Business Calendar to each admin member. Siit uses this to determine their availability when routing requests automatically within that inbox.
Because the calendar is set at the inbox level, the same admin can have different calendars in different inboxes. An admin who covers EU hours in the IT inbox can run on a different schedule in a secondary or on-call inbox.
**Step 4 — (Optional) Handle requests outside working hours**
If you want to do something specific when a request arrives and no admin is available, set up a workflow:
* Trigger: Request submitted
* Condition: Outside all active calendar hours
* Action: Send an auto-reply, assign to an on-call inbox, or notify a Slack channel
**Recommended setup by team type**
**Single-location team**
One calendar is enough. Create it once, attach it to your SLA Rules, assign it to your admins. Done.
| | | | |
| ------------- | ------------ | --------------- | ------------------------- |
| **Calendar** | **Timezone** | **Hours** | **Use** |
| Support — CET | CET | Mon–Fri 9am–6pm | All SLA Rules, all admins |
**Multi-region team**
Create one calendar per region. Attach each to the SLA Rules and admins that belong to that region.
| | | | |
| --------------- | ------------ | ------------------- | ---------------------- |
| **Calendar** | **Timezone** | **Hours** | **Use** |
| EU Support | CET | Mon–Fri 9am–6pm | EU SLA Rule, EU admins |
| US East Support | ET | Mon–Fri 9am–6pm | US SLA Rule, US admins |
| 24/7 On-call | UTC | All days, all hours | P1 Incident SLA Rule |
With this setup, a P1 ticket submitted at 2am routes to your on-call queue. A standard request submitted at 9am CET routes to the EU team. The US team's SLA clock doesn't start until their working day begins.
**Shift-based team**
Create one calendar per shift and assign each to the admins on that shift.
| | | |
| --------------- | ---------------- | --------------- |
| **Calendar** | **Hours** | **Assigned to** |
| Morning shift | Mon–Fri 7am–3pm | Shift A admins |
| Afternoon shift | Mon–Fri 3pm–11pm | Shift B admins |
A ticket submitted at 4pm routes to Shift B automatically — not to someone who clocked out at 3pm.
**FAQ**
**What happened to Office Hours?**
Office Hours no longer exists as a separate setting. Your previous schedule has been migrated into a Business Calendar called "Office Hours" in **Settings → Business Calendars**. It works exactly as before — you can edit it, rename it, or use it as the starting point for additional calendars.
**I was using Office Hours for SLA timing. Do I need to reconfigure anything?**
No. Your Office Hours schedule was migrated automatically into a Business Calendar called "Office Hours", and all your SLA Rules now reference it by default. Your SLA behavior is unchanged.
**I had SLA settings configured per service. Where did those go?**
They've been migrated to SLA Rules in Settings → SLA Rules. For each distinct SLA configuration you had across your services, a corresponding SLA Rule now exists. Your actual SLA behavior — timers, targets, pause rules — is unchanged.
**Can one admin have different calendars in different inboxes?**
Yes. Calendar assignment happens at the inbox level, not at the admin level globally. The same admin can be assigned the "EU Support — CET" calendar in the IT inbox and a different calendar in an on-call or secondary inbox. Configure this in each inbox's settings independently.
**What happens when a request comes in and no admin is within working hours?**
By default, the request lands in the inbox and waits for the next available admin. If you want a different behavior — an auto-reply, an on-call escalation, a Slack notification — set that up in a workflow using the "outside office hours" condition.
**Can I use different calendars for different SLA targets within the same team?**
Yes. Create one SLA Rule per priority or service tier, and attach the relevant calendar to each. For example, your P1 rule can use a 24/7 calendar while your standard requests use a Mon–Fri 9am–6pm calendar.
**Does changing a calendar affect SLAs already in progress?**
Calendar changes apply to new requests from the moment you save. Requests already open keep their original SLA calculation until they close.
**Can I delete a calendar?**
You can delete a calendar that isn't attached to any SLA Rule or admin. Remove those references first, then delete.
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.
Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:
```
GET https://docs.siit.io/guides/workspace/business-calendars.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
