# Using Availability Schedules

## Defining Blocks of time in the Schedule Web Control

There are two ways to use [Availability Schedules](../../studio/studio/builder-bar/schedules-builder) in a [Scheduler Web Control](../../web-controls/scheduler-web-control): they can be used to set either the **calendar** or the **calendarRestriction**. Note that associating a value with **calendar** entails selecting an Availability Schedule from a dropdown of available options, whereas associating a value with **calendarRestriction** requires entering the key associated with the desired Availability Schedule.&#x20;

![2021-09-28\_11-56-25.png](https://3333962744-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FbnBffrSN2FHLC5cM89AM%2Fuploads%2Fgit-blob-ccae8f4d74b14279def667ba4424d2b23684b8d8%2Fusing-availability-schedules-v183-0.png?alt=media)

To look up or even edit the key associated with any individual Availability Schedule, toggle to [Schedules Builder](../../studio/studio/builder-bar/schedules-builder) and inspect the Availability Schedule of interest.

A set **calendar** value is required for a scheduler to run as intended. The blocks of time defined by the Availability Schedule selected as the **calendar** are the appointment windows available for users to select.

A set **calendarRestriction** value is optional, but should it be defined, available appointment windows will be restricted to only the blocks of time encompassed by the Availability Schedule associated with **calendarRestriction**.

When used in tandem, the **calendar** value is meant to define day-to-day behavior (such as how long each appointment window is) while the **calendarRestriction** value accounts for holidays and provides a sanity check to ensure the Availability Schedule associated with the **calendar**isn't allowing appointments to be made during off hours.&#x20;

Best practices dictate that the Availability Schedules used to define **calendarRestriction** values should not consist of any Time Slots with split slots: the value given by **calendarRestriction** needs to define large blocks of time capable of encompassing smaller ones, not small appointment windows.

### Using pre-configured Availability Schedules to set **calendarRestriction** values

Out of the box, Airkit's [Schedules Builder](../../studio/studio/builder-bar/schedules-builder) comes with several Availability Schedules (as well as their component Time Slots) pre-configured. All pre-configured Availability Schedules define the blocks of time in which [TCPA regulations](../../security-and-compliance/tcpa) allow automated calls. Because these regulations vary subtly between states, timezone, and other information regarding locale, each relevant locale has its own associated Availability Schedule. Each follows the same naming convention: they begin with "TCPA", followed by the abbreviation of the relevant state, followed by information on the exact locale, each separated by hyphens.

These pre-configured TCPA Availability Schedules are designed to define **calendarRestriction** values: the blocks of time they define are large and broad, containing no Time Slots with split slots. When used in tandem with a custom-made Availability Schedule as the **calendar** value, a TCPA Availability Schedule ensures that all appointments made with a scheduler will fall within the windows of time allowed by TCPA regulations in the relevant locale.

TCPA Availability Schedules should not be used to set **calendar** values.

### Setting **calendarRestriction** dynamically

Because the value of **calendarRestriction** is set by an [Airscript](../../working-with-data/working-with-data-overview/airscript-quick-start)-parsable key – a shorthand [text](../../variable-data-types/the-text-variable-data-type) identifier that refers to an Availability Schedule as defined in the [Schedules Builder](../../studio/studio/builder-bar/schedules-builder) – it can be defined in terms of Airscript functions as well as a hardcoded string.

## Initializing the Actor

The `calendar_restriction` Actor property expects an Availability Schedule key. Should one be defined upon Actor initialization, the sending of Notifications from a [Journey Step](https://github.com/airkit/airkit-docs/blob/master/docs/v18-3/journey-builder.md) will be restricted to only the blocks of time encompassed by the Availability Schedule associated with `actor.calendar_restriction`. Best practices dictate that the Availability Schedules used to define `actor.calendar_restriction` values should not consist of any Time Slots with split slots. To look up or even edit the key associated with any individual Availability Schedule, toggle to [Schedules Builder](../../studio/studio/builder-bar/schedules-builder) and inspect the Availability Schedule of interest.

In most cases, the value of `actor.calendar_restriction` will be set automatically to reference an out-of-the-box Availability Schedule and enforce TCPA compliance. When an Actor is initialized with values for `actor.timezone` and `actor.region`, a value for `actor.calendar_restriction` will be defined automatically, such that:

```json
actor.calendar_restriction = "TCPA-{{actor.region}}-{{actor.timezone}}"
```

This `actor.calendar_restriction` value references references an out-of-the-box Availability Schedule that describes TCPA-compliant time windows within the Actor's region and timezone. Outgoing Notifications sent from Journey Steps will only be sent within the allowed blocks of time.
