> 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/migrate/form-router.md).

# Move a Form Router

Recreate an old Form Router as a form-triggered workflow. Keep the same qualification, ownership priority, and booking outcomes while moving distribution into queues and profiles.

Use the [previous Form routing guide](https://help.distro.so/routing/form-router) to identify the settings you need to carry over.

## Before you start

Record the connected form and mappings, ownership and distribution rule order, member selection and weights, strict/flexible distribution, event-type overrides, redirects, CRM actions, and notifications.

Prepare host calendars and CRM identity mappings.

## 1. Recreate the form source

**Distro-built form:** save the questions in **Lead forms**, then select it in a **New form submission** trigger.

**Existing website form:** choose **Connect an existing form**, map the fields, approve exact origins, and select browser response mode when the visitor should see scheduling.

The new external integration uses the original form's confirmed success. Use the generated SDK instructions rather than leaving the old router snippet as a second capture owner.

See [Forms](/forms.md).

## 2. Recreate pools and distribution

Create a profile and queue for each distinct receiving pool. Copy the intended members and relative weights.

| Old method            | New setup                                                             |
| --------------------- | --------------------------------------------------------------------- |
| Strict round robin    | Pre-picked member, or Assign from Queue followed by Earlier assignee. |
| Flexible distribution | Any available member; Show Scheduler uses the queue directly.         |

Copy the intended out-of-office and refund behavior. Do not assume old credits or counts have automatically moved into the new queue.

## 3. Recreate qualification and ownership

Use CRM Match Record steps to supply the existing relationship. Use a rulebook for ordered ownership and distribution decisions, or Branch for paths that need separate event types or flexible queue scheduling.

Put specific existing-owner rules before broader new-lead rules.

For strict assignment, a typical path is:

```
New form submission
  → Match CRM record
  → Apply Rulebook
      Resolved → Show Scheduler: Earlier assignee
      Else → Redirect or follow-up
```

Supply the match result to the rulebook on the applicable path and connect No match separately. Choose an owner or queue fallback intentionally.

For flexible distribution, let Branch choose the segment, then use the segment's queue directly in Show Scheduler. A matched owner can use **CRM record owner** with a fallback host.

Avoid assigning a member first and then assigning a second time through another queue.

## 4. Recreate event overrides and outcomes

Use a separate scheduler path for each old rule that selected a different event type.

Configure the scheduler's booked redirect and Not booked follow-up. Route disqualified leads to Redirect before scheduling.

Keep these cases distinct: unqualified, no eligible assignee, scheduler not booked, and external action failure.

A completed workflow without scheduling or redirect can use the native form's completion message.

## 5. Recreate CRM actions at the same stage

Actions that genuinely need the routing owner can follow the assignment outcome.

Actions that need the booked host or time belong on **Booked**. For flexible distribution, wait for Booked before updating the CRM owner to the actual host.

Move email checking or enrichment to supported steps before the decision, and branch on their actual outputs.

## 6. Publish and switch the form

Validate and simulate the workflow, then publish it and turn it On.

For a native form, select the published workflow version under **Change routing** and publish the form. For an external form, activate the compatible published version and install its integration.

Switch the website capture once the new path passes controlled tests. Coordinate any old in-flight requests before removing their integration.

## Acceptance tests

| Test                        | Expected result                                               |
| --------------------------- | ------------------------------------------------------------- |
| Existing CRM relationship   | Intended owner, or the configured owner fallback.             |
| Qualified new lead          | Correct queue and event type.                                 |
| Disqualified lead           | Intended completion or redirect, without an unwanted booking. |
| Missing qualification field | Explicit missing-data behavior.                               |
| Unavailable owner or pool   | Intended fallback or follow-up.                               |
| Successful booking          | Correct host, calendar event, CRM activity, and messages.     |
| Visitor does not book       | Intended Not booked follow-up.                                |
| Original form fails         | No workflow started by the confirmed-success integration.     |

Use [Logs](/workflows/logs.md) to inspect each result.


---

# 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/migrate/form-router.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.