Public scheduling

Public scheduling lets admins publish controlled booking links for calendar owners without giving requesters direct calendar access. In personal accounts, the calendar owner is also the admin.

The mental model is:

1. An admin creates a public link for a calendar owner.
2. An admin publishes one or more meeting types on that link.
3. Requesters submit booking proposals through the public page or public API.
4. Openavail applies owner policy, trust rules, allocations, and calendar availability before a request can become a booking.

Public scheduling is not a separate calendar product. It is another entry point into the same Openavail arbitration layer.

Overview

A public link is the requester-facing URL:

/public/schedules/jane/demo

The dashboard calls this a public link. API types may still call the same resource a boundary.

Each public link belongs to one calendar owner. A customer can create more than one link for the same owner, for example:

/public/schedules/jane/demo
/public/schedules/jane/office-hours

The readable path after the owner prefix is the part you choose in the dashboard.

Setup checklist

Admins can configure public scheduling from Scheduling links in the dashboard. Non-admin workspace members do not see this configuration surface in beta. In personal accounts, this still feels like owner control because the owner is the admin.

1. Create or choose a public link.
2. Publish at least one meeting type.
3. Choose visibility: everyone, verified requesters, or selected audiences.
4. Optional: add verified domains, requester identities, credentials, and audiences in Trust and Audiences.
5. Optional: create bookable allocations for the selected meeting type.
6. Copy the public URL and test it in a private browser window.

If a public link is disabled, requesters see an unavailable-link message. They do not see the internal form state, owner policy, private conflicts, or debugging details.

Create a public link

The create form asks for:

Field	Meaning
Owner	The calendar owner whose time this link requests.
Link path	The readable path requesters will use after the owner prefix.

The dashboard composes the owner prefix for you. If the owner prefix is:

/public/schedules/jane/

and you type:

demo

the public URL becomes:

/public/schedules/jane/demo

Pasted full public paths are accepted. The UI normalizes the path before sending it to the API.

Publish meeting types

A meeting type is a public option mapped to one internal meeting class.

The public form uses:

Field	Requester sees it?	Notes
Name	Yes	Public label, such as Intro call.
Description	Yes, optional	Short context for requesters.
Internal class	No	Maps the public option to the owner's meeting class policy.
Duration	Yes	Fixed meeting length.
Visibility	Indirectly	Controls who can see the option.
Attendee cap	No	Enforced when the requester submits.
Preempt policy	No	Cannot be more flexible than the internal class.
Auto-book	No	Only valid when owner policy allows it.
Show suggested times	Yes, when enabled	Shows safe suggested options, not guaranteed slots.

Click a meeting type row to open its details. Rows are not always open by default, so the list stays compact.

Booking policy

Visibility decides who can see a meeting type:

Visibility	Meaning
Everyone	Any requester using the public link can see it.
Verified requesters	Only requesters with a valid requester credential, and any matching verified-domain context, can see it.
Selected audiences	Only requesters matching at least one selected audience can see it.

The attendee cap includes the requester. If the cap is 1, the requester cannot add extra guests.

The public preempt policy cannot be more flexible than the mapped internal meeting class. If the internal class is protected, the public option cannot silently replace or move other meetings.

Auto-book skips owner review only where the owner's policy allows it. Otherwise public requests enter the owner approval queue.

Suggested times

Enable Show suggested times when requesters should see safe proposed options on the public form.

Suggested times are computed from Openavail's view of the owner's availability, meeting type policy, allocations, rules, holds, and current bookings. They are cached for speed, but they are not promises.

Openavail rechecks availability before treating a suggested time as real:

1. The requester opens the public form and sees suggested times.
2. The requester chooses one and submits.
3. Openavail validates the selected window again.
4. If the time is still valid, the request continues.
5. If the time changed, the requester sees that the suggested time is no longer available.

Use suggested times for requester UX. Do not treat them as calendar holds.

Requester flow

The public requester form asks for:

Field	Required	Meaning
Meeting type	Optional when free-text requests are allowed	The public option the requester wants.
Your email	Yes	The person submitting the request.
Your name	Optional	Display context for the owner.
Additional guest emails	Optional	Extra attendees, separated by commas or new lines. The requester is included automatically.
Time window	Required for structured meeting types	The range Openavail can search inside.
Reason or message	Optional for structured requests; required for free-text requests	Context for the owner.

After submit, the requester receives a public status link. Anonymous requests may also receive a contact confirmation link. Confirmed requests can enter the owner review queue.

What requesters never see

Public pages must not expose:

• Internal proposal IDs
• Private calendar conflicts
• Hidden meeting types
• Raw owner availability
• Audit history
• Private configuration controls
• Meeting class internals

The public status page only returns a safe public status, such as pending review, booked, rejected, expired, withdrawn, countered, or needs more information.