Scheduling is the platform’s shared diary. It holds appointments against the people in your organisation, calculates who is genuinely free before anything is booked, and lets external contacts book themselves in through a public offering page. It is deliberately a shared service — like chat — so HR interviews, CRM meetings and Operations site visits all live on one calendar rather than each app keeping its own. Cancellations and reschedules can be routed for approval, reminders and confirmations go out through the platform’s Communication Hub, and every appointment can be attached to the record it belongs to.
This guide is a reference for what the module does and how the pieces fit together. It describes IXL CORE version 1.0.
Overview
At a glance, Scheduling covers these connected areas:
- Appointments — the calendar entries themselves, with attendees, links and a lifecycle.
- Availability — each person’s working hours, blocked days and bookable slots.
- Booking pages — public, self-service offerings that external people can book against.
- Public booking — the tokenised, no-login surface that outside contacts use.
- Reminders & confirmations — automatic messages sent when an appointment is booked or approaching.
- Settings — the organisation’s business calendar, default duration, buffers and approver.
Every record is scoped to your organisation, and every action is governed by permissions (see Access & permissions).
Appointments
An appointment carries a title, an optional description, a type (meeting, interview, onboarding, site visit, service, review or other), a start and end time with a timezone, an all-day flag, a location and an optional meeting link. Each has an organiser and a list of attendees — either internal staff (chosen from the people directory) or external guests captured by name and email. Every appointment gets a reference number and a generated .ics file so it can be added to any external calendar.
When you create or reschedule an appointment, the module checks for conflicts before saving: it locks the affected staff rows and rejects a slot that overlaps another active appointment or approved leave for the organiser or any internal attendee. A double-booking is refused with a clear error unless the person holds the dedicated conflict-override permission, in which case the override is recorded in the audit trail rather than silently allowed.
An appointment moves through a lifecycle — scheduled → confirmed → in progress → completed, or is set aside as cancelled, no-show or rescheduled. Confirm, complete and no-show are one-click transitions. Cancel and reschedule are treated as approval moments: when an approver can be resolved (an explicit approver, the organisation’s configured default, or the organiser’s line manager from HR), the request is routed for sign-off; otherwise it is applied immediately. Attendees can record their own RSVP (invited, accepted, declined or tentative).
A recurrence rule expands into a chain of concrete instances, and a cancellation can either drop a single instance or the whole series in one action.
Typical steps
- Go to Scheduling → Calendar and create an appointment, setting the time, organiser and attendees.
- The slot is conflict-checked; a confirmation and a scheduled reminder are queued automatically.
- Confirm, complete, cancel or reschedule as the appointment progresses — cancel and reschedule may route for approval.
Availability
Each person has an availability record that drives the free-slot maths: a timezone, working hours per weekday, specific blocked days, a default slot length, and buffers to leave before and after each booking. A person can be marked bookable or not. The slots endpoint composes this record with the organisation’s business calendar, existing appointments and approved HR leave to return the genuinely free windows for a given date range and duration — so nothing is offered that the person cannot actually take.
A lightweight people directory backs the organiser and attendee pickers, resolving staff by name or email without exposing internal data.
Booking pages
A booking page is a public offering you publish so people outside the organisation can book time. It has a title, description, appointment type, a fixed duration, before/after buffers, a booking horizon (how far ahead bookings are allowed), a minimum notice period, a timezone, and one or more providers (the staff whose availability backs it). Each page is either active or not, and carries an unguessable public slug that acts as its address.
The number of active booking pages is subject to your plan’s external-booking entitlement; activating one beyond the limit is refused with a message showing the cap. Deleting a page deactivates it and detaches its providers.
Typical steps
- Go to Scheduling → Booking pages and create a page, choosing the duration, horizon, notice and providers.
- Activate it and share the public link.
- Bookings made against the page appear on the calendar as ordinary appointments.
Public booking
The public booking surface needs no login: the booking page’s slug (or a per-appointment public hash) is the credential, exactly as the platform’s other tokenised public flows work. An external person can view the offering, fetch the free slots over a date range (clamped by the page’s horizon and minimum notice), and book by supplying their name, email and chosen slot — which creates the appointment. If the slot was taken in the meantime, the booking is refused so two people cannot claim the same time.
After booking, the person gets a confirmation summary and can download the .ics. They can request a cancellation or reschedule against their appointment hash, but those requests route through approval — an external person can never mutate the calendar directly.
Reminders & confirmations
When an appointment is booked, an immediate confirmation is sent to attendees, and a reminder is scheduled to fire ahead of the start time using the organisation’s configured lead time. A reschedule re-arms the reminder against the new time. These messages go out through the platform Communication Hub, subject to the tenant’s messaging configuration.
Settings
Scheduling keeps no private settings store of its own — its configuration lives on the platform’s shared-settings engine. A manager can set the organisation’s working days, timezone, default appointment duration, before and after buffers, the reminder lead time, and the default approver for cancel and reschedule sign-offs. The approver is always chosen from a people picker, never typed as a raw id, and every change is audited.
Access & permissions {#access-and-permissions}
Every Scheduling action maps to a specific capability — for example scheduling.appointments.view, scheduling.appointments.manage, scheduling.appointments.override_conflict, scheduling.availability.manage, scheduling.booking_pages.manage and scheduling.settings.view are each separate permissions, enforced on every request rather than merely hidden in the interface. Overriding a conflict needs its own dedicated capability beyond ordinary manage rights. Records are scoped to the organisation, and a booking-page slug or appointment hash from one organisation can never reach another — the lookup simply returns not-found. The number of active booking pages is additionally governed by the external-booking entitlement on your plan.
How Scheduling connects
Scheduling is a shared platform service, not a standalone app:
- HR supplies the workforce identities behind organisers and attendees, the approved leave that blocks slots, and the line-manager reporting line used to resolve a cancel or reschedule approver.
- CRM, Operations and other apps attach their own records to an appointment through a polymorphic link, so a meeting or site visit is reachable from the deal or job it belongs to.
- The approvals engine handles cancel and reschedule sign-offs, including every external request from a public booking.
- The Communication Hub delivers booking confirmations and reminders.
- The shared-settings and audit engines hold the business-calendar configuration and record every override and change.
That is the point of building it once: you keep a single diary for the whole business, and every app books against the same conflict-checked availability instead of rolling its own.