Calendars
Calendars are global (not workspace-scoped).
Task walkthrough: Manage properties, calendars, and tags. This page is the full configuration and troubleshooting reference.
A calendar is a named set of dates — typically holidays or blackout days. Calendars are used to exclude days from scheduling.
Fields
| Field | Notes |
|---|---|
name | Unique calendar name. 3–255 characters, following the platform naming rules. |
description | Optional. |
dates | A list of dates, each YYYY-MM-DD. |
Working with the calendar list
The Calendars tab of the Toolkit is a single list, and a calendar is created, edited and viewed in one dialog over it. There is no separate detail page to open — the pattern every Toolkit type now follows.
| Where | What it does |
|---|---|
| New Calendar | Opens the editor for a new calendar. |
| Row menu → Edit | Opens the same editor on that calendar. Reads View instead when you don't have permission to change calendars, and the editor opens read-only. |
| Row menu → Cross Reference | Shows what refers to this calendar — see What refers to a calendar. |
| Row menu → Delete | Deletes the calendar, once it has checked that nothing refers to it — see Renaming and deleting. |
| Double-clicking a row | The same as Edit. |
Sort the list by name, date count, created, or updated. Date count is the number of dates the calendar holds, which is the quickest way to spot a calendar that was never filled in.
The calendar editor
Name, description and dates are all edited in one dialog.
- Pick dates from the calendar grid. It is a scrollable, multi-month picker that opens on January of the current year, with arrows to move a year at a time. Selecting a day adds it; selecting it again removes it.
- The selected dates are listed alongside, with a running count. Remove one from its own row, or tick several and delete them together.
- Upload dates from a file with Upload → iCal or Upload → JSON. The file is read in your browser and merged into the dates you already have — nothing is saved until you save the calendar.
| Upload format | What is read |
|---|---|
iCal (.ics) | The start date of every event in the file. |
| JSON | Either a bare array of YYYY-MM-DD strings, or an object with a dates array of them. |
After an upload you're told how many dates were added and how many entries were skipped.
An iCal recurring event is not expanded — only its start date is imported, and the upload summary says how many events that applied to. Import a file with the occurrences written out, or add the remaining dates in the picker.
When you open an existing calendar the form appears only once its dates have loaded, so a save can never replace a stored date set with an empty one. If loading fails you get an error instead of an editable form.
How calendars are used
- As an exclusion calendar on a frequency — matched dates that fall on a calendar date are excluded.
- As an Annual Plan frequency's own calendar, where its dates are the days the job runs on.
- As an additional holiday calendar on a workflow's schedule (see Scheduling and the run).
What refers to a calendar
Nothing that references a calendar is a job. A calendar is set on a workflow's schedule, or named by a frequency's pattern — so Cross Reference shows two sections, and neither is the Jobs list you see for a tag or a threshold:
| Section | What it lists |
|---|---|
| Workflows | Workflows whose schedule sets this calendar as its Additional Holiday Calendar. |
| Frequencies | Frequencies whose pattern names it — as an exclusion calendar, or as an Annual Plan's own calendar. |
The list is paginated. When there are more references than the dialog was given, it says Showing N of M references rather than presenting a first page as the whole set.
Renaming and deleting
A reference is stored as an id plus a name, and the id is what identifies the calendar. So:
- Renaming a calendar does not break anything that uses it. The name stored beside the id is refreshed the next time the referring workflow or frequency is saved.
- A calendar that is in use cannot be deleted. Selecting Delete checks the references first: if it finds any, the confirmation lists what refers to the calendar and the delete cannot go ahead, rather than being attempted and refused. References are counted the same way the save path resolves them. If the check itself fails you are told so, and the delete is unavailable until it succeeds — a failed lookup is never read as "nothing refers to it".
- A reference whose stored id resolves to nothing falls back to its name, and that fallback is counted too — so a calendar recreated under the same name is protected by the references that had come to depend on it.
An additional holiday calendar is an optional setting, so a workflow whose stored reference no longer resolves still saves normally; the unresolvable reference is left as stored and logged. An Annual Plan is different — the calendar is the schedule, so there the reference must resolve.
- Calendars are shared across workspaces.
- To see calendars applied before a run, use the workflow editor's Forecast view: the exclusion calendars on its frequencies and the workflow's holiday calendar are resolved before the dates are calculated, the same as in the build. The forecast in the Frequencies dialog does not apply calendars — see Frequencies.
- An Additional Holiday Calendar on a workflow now takes effect at all. Earlier builds stored the setting and never applied it — to the Forecast view or to the real build. If you set one before and concluded it did nothing, it works now, so re-check the dates it removes.
- A calendar date is what makes a day non-working for a workflow that applies it, which is what the working-day rules in Frequencies count.
- A cleared description is saved as cleared — emptying the field removes the text rather than leaving the old value in place.