Loading

Creating a Calendar

A calendar is quick to create and easy to configure in an order that produces rework.

Where to find it

Architect Panel → Layout & Pages:

  • Booking Calendars — the calendar, then its row actions for everything else

Decide first

  1. What is being booked — a person’s time, a room, a piece of equipment, a place on a class.
  2. The unit — how long the shortest booking is.
  3. Who may book — everybody, signed-in users, one group.
  4. Whether attendance matters.

Those four decide most of the configuration.

Then build in this order

  1. Create the calendar and set slot size, view mode and the advance limit.
  2. Add locations, if bookings happen in more than one place.
  3. Add event types — what can actually be booked.
  4. Add form fields to each event type, if you need information from the person booking.
  5. Add available periods, recurring where the pattern repeats.
  6. Add unavailable periods for known closures.
  7. Set permissions.
  8. Set up confirmations.
  9. Book a test slot as a real user.

Availability last among the configuration, because it depends on the event types and locations existing.

One calendar or several

One calendar per bookable thing where each has its own availability — three consulting rooms with different opening hours are three calendars. One calendar with locations where availability is common and only the place differs.

Getting this wrong produces either a calendar that cannot express your availability, or five calendars maintained in parallel.

Use the HTML areas

Content above and below the calendar is where you explain what somebody is booking, what to bring, and what happens if they cannot attend. That is the cheapest reduction in support contact available.

Set permissions before publishing

So the calendar is not bookable while half-configured. A calendar with no availability and no event types, reachable by customers, generates confused enquiries.

Test as somebody else

Your own account probably has permissions nobody else does. Book as a test user with exactly the access a real person would have.

Worked example

A training provider set up one calendar per venue because opening hours differed, each with recurring weekday availability, three course types as event types, and a form field asking about accessibility requirements. Permissions were set before it went live, and a test booking was made from a fresh account.

Recommendations

  • Decide the four questions before creating anything.
  • Availability last — it depends on the rest.
  • Separate calendars where availability genuinely differs.
  • Test from an account with real permissions.