How does the engine handle complex timezones?

Schedules are authored in local 'Wall Clock Time' with a designated timezone (e.g., America/New_York). The engine automatically calculates the exact UTC boundaries, correctly handling shifting Daylight Saving Time rules for every resource.

Can I book multiple dependent resources at once?

Yes. You can perform atomic multi-resource bookings. For example, a medical surgery can simultaneously reserve a Surgeon, an Operating Room, and specialized equipment in a single, conflict-free transaction.

Is there built-in support for waitlists?

Absolutely. When a resource is fully booked, users can JoinWaitlist for their desired interval. The system tracks queue positions and registers intent, allowing you to easily promote users when cancellations occur.

Are there any 'per-booking' or usage fees?

The proposed model is source licensing rather than per-booking metering. Infrastructure, provider, support, and license terms are confirmed for the design-partner deployment; capacity is validated against the target workload.

Scheduling design-partner pilot

Turn working hours into bookable time without guesswork.

Scheduler is the design-partner pilot for tenant-aware resources, working hours, exceptions, availability, reservations, and collision-aware booking workflows.

Plan a scheduling pilot Read the documentation

Review the pilot boundary

Scheduler domain

Availability and reservation workflow

Design-partner pilot

Operational workspace

Every slot is derived from rules, resources, and current state.

Working hours loaded

Resource schedule, timezone, and tenant policy assembled

Configured

Exceptions applied

Closures, overrides, and existing reservations remove time

Calculated

Slot requested

The product asks for eligible time within its constraints

Available

Reservation confirmed

Availability is checked again before state is committed

Reserved

Timezone awareResource scopedPilot validated

Lifecycle: Design-partner pilot
Interfaces: REST · Connect/gRPC · MCP via Agent Gateway
AWS path: Design-partner pilot
Commercial basis: Design-partner pilot terms

Product outcome

A calendar shows time. A scheduling product must decide what can actually be booked.

Real availability depends on resource rules, local time, exceptions, existing reservations, buffers, and product policy. Scheduler brings those decisions into one domain so booking interfaces and operational teams work from the same answer.

One availability model

Working hours, exceptions, resource state, and reservations contribute to the same result.

Tenant-aware booking rules

Each customer can carry its own resources, timezones, operating constraints, and workflows.

Collision-aware reservations

The booking path checks current availability before confirming competing requests.

01 / Domain capabilities

A complete Scheduler boundary, not a thin endpoint wrapper.

Each capability belongs to the same tenant-aware service contract and can be adapted in the licensed source.

Working hours and exceptions

Model regular operating windows, local timezone context, closures, and date-specific overrides for each resource.

Availability calculation

Derive eligible time from schedules, exceptions, existing reservations, buffers, and request constraints.

Resource composition

Represent bookable people, rooms, equipment, or other tenant-owned resources inside the same scheduling boundary.

Reservation lifecycle

Create and manage booking state through a collision-aware workflow that can connect to customer notifications.

02 / Product workflow

One path from product intent to an enforceable result.

The overview stays business-readable. The documentation and published contract contain field-level detail.

01
Configure the resource
Define the tenant, timezone, working windows, exceptions, and product-specific scheduling policy.
02
Ask for availability
Submit the resource and time constraints needed by the customer-facing booking experience.
03
Select and reserve
Choose an eligible slot and confirm it through the collision-aware reservation path.
04
Operate the booking
Update the reservation lifecycle and connect reminders or changes through Notifications.

03 / Technical depth

Clear operational boundaries for the team that owns it.

Support is guided design-partner support. Deployment, updates, and customer-cloud responsibilities are reviewed before purchase.

Define the pilot booking policyscheduler-policy.yaml

resource: consultation-room
timezone: Europe/Kyiv
working_hours:
  monday: ["09:00-17:00"]
  tuesday: ["09:00-17:00"]
booking:
  duration_minutes: 45
  buffer_after_minutes: 15
  collision_check: required

Scheduling state

Resources, working hours, exceptions, availability inputs, and reservations form one tenant-aware model.

Timezone boundary

Local operating rules remain attached to an explicit timezone while interfaces exchange unambiguous timestamps.

Notification connection

Reservation confirmations, reminders, changes, and cancellations can hand off to Notifications.

Open documentation

04 / Where it fits

Scheduler supports products with real tenant and commercial complexity.

These are product patterns, not customer case studies or measured outcomes.

Pattern 01

Appointment products

Offer bookable time for clinicians, advisors, consultants, or service teams while respecting resource policy and tenant context.

Pattern 02

Shared resource booking

Coordinate rooms, equipment, staff, or property access without treating every calendar event as automatically available.

Pattern 03

Operational reservations

Give internal teams one reservation lifecycle for rescheduling, cancellations, reminders, and exception handling.

Ownership model

Own the service without owning every release problem.

The source license, update term, support boundary, and customer-cloud responsibilities remain explicit. Missing domain work can be scoped as a custom module instead of hidden in a roadmap promise.

Pilot source delivered for the agreed scheduling scope

Documented REST and Connect/gRPC integration path

Customer-controlled resource and reservation data

Missing booking rules scoped and validated with design partners

No public evidence record

Customer-cloud deployment path

Depends on identity, notifications

Scheduler architecture review

Put Scheduler behind a product boundary your team can own.

Bring the tenant model, workflow requirements, cloud target, and any missing module. We will map the service, its dependencies, and the delivery path before discussing a license.

Plan a scheduling pilot Build my architecture

Frequently Asked Questions

Common Questions & Answers

Everything you need to know about integrating and hosting this Launch Rail service.

Related services

Notifications Submissions Identity

Related use cases

Healthcare PropTech LegalTech