> 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/get-started/admin-setup.md).

# Admin setup

Prepare your workspace so a prospect can reach the right teammate and book a meeting.

**You need workspace admin access.** Decide which team will receive your first leads and which website form or seller action will start the journey.

## 1. Connect your tools

Connect the CRM you use for ownership matching and record updates. Connect conferencing if meetings need a video link. Connect Slack, email, or enrichment providers only when your first workflow needs them.

Ask each host to connect a primary calendar and set their working hours. A person can receive a record assignment without a calendar, but needs a usable calendar to host a meeting.

See [CRM connections and identities](/data-and-integrations/crm.md) and [Calendars and availability](/scheduling/availability.md).

## 2. Create a routing profile

Open **Queues → Routing profiles** and create a profile.

For a simple demo queue, choose **Meetings**, **Even rotation**, and the scheduler times that fit your team. Choose **Pre-picked member** to select one host before showing times, or **Any available member** to offer times across the queue.

Review out-of-office checks and turn refunds. See [Routing profiles](/routing/profiles.md).

## 3. Create a queue

Open **Queues** and create a queue. Choose the profile, then add individual members or linked teams.

Use equal weights to start. Confirm that the queue and its members are active and hosts have calendars. See [Create and manage a queue](/routing/queues.md).

## 4. Prepare the event type

Open **Event types** and create or review the meeting. Set its duration, location, booking questions, and availability. If you want workflows to use the event's hosts, configure its **Hosts** section.

See [Event types and hosts](/scheduling/event-types.md).

## 5. Build the first workflow

Create a workflow with the trigger you need. For inbound, start with **New form submission**. For a seller-led handoff, use **Browser extension**.

Add **Show Scheduler**, select the event type, and choose the queue as the host source. Add follow-up actions to **Booked** and **Not booked** as needed.

See [Create a workflow](/workflows/create-a-workflow.md).

## 6. Test, publish, and activate the source

Use **Validate** and **Simulate** first. Publish the workflow, turn it **On**, then connect the source to the intended published version.

A native lead form must select that workflow version and be published. An external form connection must be activated separately. See [Test and publish](/workflows/test-and-publish.md).

## Check the complete journey

Use controlled test details on the real form or seller surface. Confirm the route, available times, booking, CRM update, and notification. Review the workflow's **Logs** and the queue's **Usage log**.

Publishing a workflow does not by itself install it on a website. If live events remain unavailable, check workspace activation with Distro support.

## Detailed setup

Use [Members and invitations](/settings/members.md), [Connected identities](/settings/identities.md) and the provider-specific [Integration guides](/integrations.md). Finish with [Sending domain](/settings/sending-domain.md), [Workspace branding](/settings/branding.md), [Booking themes](/settings/booking-themes.md) and [Workspace alerts](/settings/workspace-alerts.md).

For a complete first journey, follow [Demo request to booked meeting](/guides/demo-requests.md).


---

# 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/get-started/admin-setup.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.