App Suite Releases
  • 8.47
  • 8.35
  • 7.10.6
Imprint
  • 8.47
  • 8.35
  • 7.10.6
Imprint
  • Release 8.52Upcoming
    • Noteworthy Changes
      • Important Changes
      • App Suite Middleware
      • OX Documents
    • Changelogs
      • App Suite UI
      • App Suite Middleware
      • Additional Components
        • AI Service
        • Booking Service
        • OX Guard UI
        • OX Documents
        • Switchboard
        • Changelog
    • Helm Charts
      • AI-Service documentation
      • App Suite Stack Chart
      • Booking
      • Helm Chart core-cacheservice
      • Helm Chart core-documentconverter
      • Helm Chart core-imageconverter
      • core-mw
      • UI Service
      • Switchboard
  • Release 8.51
  • Release 8.50
  • Release 8.49
  • Release 8.48
  • Release 8.47LTS
Maintained. Older releases are best effort.
Upcoming
Not released yet
LTS
Long-term support branch

Booking Service

0.5.0 - 2026-07-31

First release. Booking adds two kinds of self-service scheduling to OX App Suite: Doodle-style Appointment Polls and Calendly-style Appointment Booking, plus an agent surface onto the latter's public flow. Owners work from a plugin in the App Suite side panel; invitees, bookers and agents need no account, because the public link is the capability. Agreed times become real App Suite Calendar appointments and reach everyone as calendar invitations by email.

Coming from the preview version: the Helm values have changed. Resource naming, the image values, the security-context blocks, and how the database and free/busy credentials are wired all differ, among others. Review your values file against the current documentation and adjust it before upgrading, rather than reusing the preview's file as it stands.

Added

  • Appointment Polls
    • Polls with public, login-free voting. Owners propose a set of times and share the poll's link. Invitees open it without an App Suite account and mark each time yes, no or maybe, shown in their own time zone. Polls clean themselves up once their times have passed, so old ones don't pile up.
    • Voters are invited automatically. Voters leave a name and an email address when they save their votes, and owners can require the address. Finalizing invites everyone who gave one to the appointment, and the owner sees beforehand who will be notified and who will not.
    • Finalize and reopen. Picking the winning time closes the poll and puts the appointment in the owner's calendar. Reopening collects votes again and leaves that appointment alone.
  • Appointment Booking
    • Bookable appointment types. Owners publish what can be booked (title, description, location, duration) and when: a weekly availability schedule, prefilled from their calendar working hours, with single dates blocked or reshaped where needed. Booking rules keep the offer realistic, covering buffers around appointments, how much notice is required, how far ahead people may book, and an optional daily cap. Types can be paused without losing their setup, and free times are worked out as the page is opened, so changes take effect immediately without disturbing bookings already made.
    • Public booking page. Visitors see only the days that still have something free, pick a time in their own time zone and language, and confirm with their name, email and an optional message. The page never explains why other times are unavailable. Whoever confirms first gets the time, so the same slot cannot be booked twice.
    • Bookings land in both calendars, managed by link. A confirmed booking blocks the time immediately and arrives in both calendars as an ordinary calendar invitation. The booker's confirmation mail carries a link for managing that one booking, and cancelling from either side frees the time again and tells the other party.
    • Rescheduling moves the appointment. Picking a new time shifts the existing appointment rather than cancelling it and starting over, and each side gets a single mail showing the previous time against the new one. The booker can give a reason, which reaches the owner as exactly that.
    • Calendar conflict checking. A booking page can take the owner's calendar into account, so times they are already busy are neither offered nor bookable. It considers all of the owner's own calendars, but not calendars subscribed from elsewhere, and where a deployment provides no free/busy data the setting is not offered at all.
    • Bookings are not kept forever. Booking records hold personal data of people outside the organization, so they are deleted automatically once the appointment is past, after a period operators configure. Appointment types themselves stay.
  • Agent access
    • Booking pages serve AI assistants as well as people. The public booking flow is available over the Model Context Protocol, so someone can hand a booking link to their assistant and have it list the free slots, book one on their behalf, and cancel or move it later. Owners can put an agent in front of their own page as a receptionist and let it book callers in. Either way it stays an ordinary booking, with the same confirmation mail and manage link, and an agent can do no more than a person holding that link could. Operators choose whether to offer this at all; it is off by default.
  • In App Suite
    • The "Find time" side panel. Owners set up and keep track of both their appointment polls and their booking pages from one panel next to their calendar, and see at a glance what is still collecting votes and what is taking bookings.
    • Time slots and availability are drawn in the calendar. A poll's proposed time slots and a booking page's weekly availability are marked by dragging in the calendar week grid rather than typed into a form, and the owner's own appointments stay visible while they do it, so the free gaps are the ones they offer. Clicking a mark removes it again, and the list in the side panel stays in sync, for fine-tuning exact times and for working by keyboard alone.
Prev
AI Service
Next
OX Guard UI