Help Center

Docs

Routing Forms

Qualify before scheduling — route prospects to the right booking page or host based on their answers

What a Routing Form Does

A public form that asks qualifying questions, then sends the visitor to the right next step based on their answers.

A routing form lives at /r/[slug]. The visitor answers the questions you configured, and the first matching rule decides what happens next: book a meeting on a specific booking page, route to a specific team member, redirect to an external URL, or display a message. When the rule sends them to a booking page, the answers they just gave are pre-filled on the booking form so they don't have to retype their name, email, or any custom-question responses.

A routing form is the “qualify before scheduling” step that sits in front of a booking page. The rules live server-side and are never returned to the public form, so visitors can't inspect the page source to game the routing logic. If you only need to capture a lead rather than route one, a lead capture form (also under Admin) is the simpler tool.

Creating a Form

From Admin → Routing Forms, define the questions, then layer rules on top.

1

Open Admin → Routing Forms.

Click New Routing Form. Give it a Title and (optionally) a Custom URL slug. The slug becomes the public URL: /r/[slug]. If you leave it blank, a random short ID is used.
2

Add questions.

In the form editor, click + Add question for each piece of information you need. Pick a label, a type (text, textarea, select, multiselect, email, phone, number, date, checkbox), and toggle Required if you need an answer to route on it. For select / multiselect, paste options one per line in the format id|Label.
3

Add routing rules.

Each rule has a When block (one or more conditions) and a Then block (the action). Pick whether all conditions must match or any condition matches. Conditions use the operators below.
4

Set a default action.

The fallback when no rule matches. Usually Route to booking page pointing at your primary booking page so every visitor still ends up booking something.
5

Activate and share.

Toggle Active in the form header and click Save. Copy the public URL from the list view (the Copy button next to each form) and share it on your website, in email signatures, or via campaigns.

Question Types

What each question type accepts and how it renders.

FieldDescriptionType
textSingle-line input. Up to 500 characters.string
textareaMulti-line input. Up to 4,000 characters.string
emailSingle-line input validated as a valid email address.string
phoneFree-form phone number. Up to 50 characters.string
numberNumeric input. Use this when you want to compare ranges (greater than, less than) in routing rules.number
dateCalendar date picker. Stored as YYYY-MM-DD.date
selectSingle-choice dropdown. Define 1–50 options as id|Label pairs.enum
multiselectMulti-choice picker. Same option format as select; the visitor can pick more than one.enum[]
checkboxSingle boolean. Useful for consent or yes/no eligibility flags.boolean
A routing form supports up to 30 questions. Long forms hurt conversion — keep the qualifier to the 3–5 questions that genuinely change the routing decision and let the rest be captured on the booking page or in follow-up.

Rule Operators

What you can compare against.

FieldDescriptionType
equals / not_equalsExact match. Works on text, select, and multiselect (matches when any selected option equals the value).comparison
contains / not_containsSubstring match for text fields, or membership for multiselect.comparison
greater_than / less_thanNumeric comparison. Use on number questions, e.g., "Annual revenue greater than 1000000".comparison
in / not_inMatch against a list of values. Useful when several option ids should route the same way.comparison
is_empty / is_not_emptyNo value to type — checks whether the question was answered. The value field is disabled.comparison

Action Types

What happens when a rule matches (or when no rule matches and the default fires).

FieldDescriptionType
Route to booking pageSend the visitor to /b/[workspace]/[page]. Their name, email, and any custom-question responses are pre-filled via a one-time prefill token (?prefill=...). The token is single-use and expires 30 minutes after the routing decision.redirect
Route to specific hostSame as above, but the booking page must use a team strategy (round_robin, collective, or group). Pass the host's user_id and the booking page locks the booking to that host.redirect
Redirect to URLSend the visitor to an arbitrary external URL. Useful when an answer disqualifies them — e.g., "Sorry, you're outside our service area — visit our partner page."external
Show messageDisplay a static message inline on the form page. No redirect. Useful for "Thanks — a sales rep will reach out" responses.inline

How Rules Evaluate

First match wins, top to bottom.

Rules evaluate in the order they appear in the editor. The first rule whose conditions match wins — its action is what the visitor sees. Subsequent rules are not evaluated. If no rule matches, the default action runs. Drag rules into priority order: put your most specific qualifiers (high-value enterprise, region locks) at the top, broad fallbacks at the bottom.

If a routing rule points at a booking page that's been deleted or deactivated, the visitor sees a generic “form unavailable” message. Audit your rules after archiving booking pages.

Prefilling the Booking Page

Routing-to-booking carries the visitor's answers forward.

When a rule routes to a booking page or specific host, the form generates a single-use prefill token. The visitor lands on /b/[workspace]/[page]?prefill=<token> and the booking page looks up the token, fetches the form submission, and pre-fills the booker's name, email, and any answers to questions that match the booking page's custom intake questions. The token is hashed at rest, expires 30 minutes after issue, and can be redeemed only once — so sharing or re-loading the URL after submission silently drops the prefill rather than leaking another visitor's data.

Tracking Submissions

What happens to every submission, even when no rule matches a meeting.

Every submission is stored on the form regardless of which action ran. If the visitor provided an email and the email matches an existing CRM contact, the submission auto-links to that person record. If no match is found and the form was set to capture leads, a new lead is created with the answers attached. The form list view shows the submission count next to each form and the question count.

Security & Rate Limiting

Built-in defenses that don't get in the way of legitimate visitors.

  • Rules and the default action are never returned to the public GET — the visitor only sees questions and labels.
  • Submissions are rate-limited per IP (10/hour) and per form (60/hour). Hitting the limit returns a 429 with a Retry-After header.
  • Email submissions auto-link to existing CRM contacts only when the email matches exactly (lowercase, parameterized comparison — never LIKE).
  • Prefill tokens use 32 cryptographically random bytes, are stored as a SHA-256 hash, are single-use, and expire 30 minutes after the routing decision.
  • Inputs are stripped of control characters, capped at sane byte lengths, and validated against the question schema before write — header-injection and XSS-via-prefill are blocked at the system boundary.

Permissions

  • scheduler.view — required to see the routing-forms admin page.
  • scheduler.create — required to add a new form.
  • scheduler.edit — required to change questions, rules, default action, or activation.
  • scheduler.delete — required to remove a form. Submissions persist after deletion for analytics.
  • The public /r/[slug] page is unauthenticated — anyone with the URL can submit if the form is active.