> For the complete documentation index, see [llms.txt](https://docs.distro.so/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.distro.so/workflows/show-scheduler.md).

# Show Scheduler

Show Scheduler opens a booking calendar and continues the workflow after the prospect books or leaves the booking window without booking.

Add it on a path with a supported visitor or caller session. A background-only source cannot show a calendar to a visitor.

## Choose the meeting

Select **Event type**. Review the event's duration, location, questions, and availability before using it in the workflow.

Under **Hosts**, choose **Use event hosts** or **Choose hosts here**.

* **Use event hosts** follows the event's primary host and co-host settings. Later changes to those host settings apply without republishing the workflow.
* **Choose hosts here** lets this step define the host sources.

## Choose a host source

| Host source          | Use it for                                                                            |
| -------------------- | ------------------------------------------------------------------------------------- |
| **Queue**            | Let the queue profile offer times and select the meeting host.                        |
| **Member**           | Book one specific workspace member.                                                   |
| **Earlier assignee** | Use the person selected by Assign from Queue or Apply Rulebook.                       |
| **CRM record owner** | Use a matched record's owner, mapped to a Distro member through connected identities. |

Set a **Fallback host** when the primary host source may be missing or unusable.

Add **Additional attendees** when the meeting needs co-hosts. Required attendees must be free for a time to appear. Optional attendees are invited without their calendars limiting the times offered.

## Prefill booking details

Map **Name**, **Email**, and optional **Notes** under **Booking details** from the trigger or earlier steps.

Use the prospect's details, especially in a seller-led handoff. The seller starting the workflow is not automatically the guest.

## Set the booking window

Choose **Booking window (minutes)**: 3–60 minutes, with 5 minutes as the default.

This is the time to choose a slot in this scheduling session. It is not a 30-day reusable campaign link.

Connect:

* **Booked** to actions that need the confirmed meeting, host, and time.
* **Not booked** to follow-up when the session closes without a booking.

Not booked covers an uncompleted scheduling session; it should not be used as a synonym for a failed CRM lookup or an unqualified lead.

## Configure redirects

Use **Redirect when meeting is booked** for a thank-you page and **Redirect when meeting is not booked** for a follow-up destination.

For a booked redirect, choose how long confirmation stays visible. The supported delay is 0–300 seconds.

For connected browser forms, **Display scheduler at this URL upon redirect** can hand scheduling to another approved page. Install the same form SDK on the destination and approve its exact website origin.

## Verify the real experience

Simulation can check the path and samples. A real test is needed to verify calendars, available times, conferencing, and the final booking.

See [Calendars and availability](/scheduling/availability.md) if no times appear.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.distro.so/workflows/show-scheduler.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `build a script that syncs our docs to a CMS` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.