Blackouts & Slot Exceptions

A slot exception is a blackout: a window during which a calendar slot rule offers no availability, laid over the rule without changing it. Exceptions are how you close a public holiday, block weekly cleaning time, or shut one building for renovation — without touching your carefully built slot rules. This article, written for administrators, shows you how to add a one-off or recurring blackout, scope it from every property down to a single one, and understand how a recurring series keeps itself topped up automatically. Blackouts always win over availability, so a well-placed exception is the cleanest way to take time off the calendar.

What an exception is

An exception belongs to one Calendar Slot Rule and carries a blackout window — an Unavailable From and an Unavailable To. During slot computation, any exception whose window and scope apply knocks out the slots it covers. This holds for both Standard and Custom rules, and the rule is simple: a blackout always wins over availability. If a time is both offered by the rule and covered by an exception, it disappears from the picker.

An exception carries a name (Exception Subject), the window, an Unavailable Reason you can leave for your team, a set of optional scope fields, and — if it recurs — a frequency. We'll take each in turn.

Creating a one-off blackout

The simplest exception is a single window — a public holiday, a one-day closure:

REDA checks the window makes sense — the end can't come before the start:

Scoping a blackout

By default a blackout covers every property using the rule. You narrow it with any of four scope lookups — Region, Neighbourhood, Property Type, or a single Property. A blank scope field is a wildcard; a filled one must match the property being scheduled for the blackout to apply to it. Fill more than one and all the filled fields must match — for example Region and Property Type together hits only properties that are both in that region and of that type.

Recurring blackouts

For a blackout that repeats — a weekly deep clean, a monthly closed day — set a Recurring Frequency and an Advance Recur Instances. The frequency decides how far apart the occurrences fall; the advance count decides how many future occurrences REDA keeps generated ahead of time.

A recurring exception needs its advance count, and REDA insists on it:

Save the parent and REDA immediately creates the future occurrences as child records — one for each of your advance instances, their windows shifted by the frequency and their names carrying a numbered suffix. Each child links back to the parent, so the whole series is easy to see under the rule. The children are copies of the parent, so the scope and reason you set on the parent carry to every occurrence — you don't set them again per date.

How the series stays topped up

You never have to extend a recurring series by hand. A nightly REDA job — running shortly after midnight — checks each series and regenerates consumed occurrences, so the series always looks the configured number of instances ahead. This job is one of the few REDA jobs scheduled to run automatically out of the box; you can confirm it in the scheduled-jobs console (see Scheduled Jobs).

Editing and deleting a series

Once a recurring parent has generated its children, REDA blocks changes to the parent's end date — it prevents the edit and tells you why, to keep the parent and its children consistent. The supported way to change a running series is to delete it and recreate it with the new settings.

Deleting the parent is clean: it cascade-deletes the whole series, removing every generated child along with it. That's by design — one delete clears the entire recurring blackout.

Worked example: two blackouts

Both sit on the Residential Showings — Weekdays rule from the Calendar Slot Rules example:

The exception child list under a slot rule — the Harbour Tower Showings rule's one-off Holiday Blackout exception, with its Unavailable From / To window, Unavailable Reason and the Applicable To scope columns.

A slot exception (Holiday Blackout): the parent Calendar Slot Rule, the Unavailable From / To window and Unavailable Reason, the Recurrence fields, and the Applicable To scope lookups (Region, Neighbourhood, Property, Property Type).

Field reference

Where to go next

1. Calendar Slot Rules — the parent object and how slots are computed.
2. Short-Term Bookings — where a blackout is felt on the booking side.
3. Scheduling Showings — where a blackout is felt on the tour side.
4. Scheduled Jobs — the nightly top-up job and the jobs console.
5. Work Orders — maintenance blackouts on the same engine.

Frequently asked questions