> 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/click-router.md). # Move a Click Router Recreate the job of an old Click Router: identify the prospect, check the existing owner, use a fallback pool, and offer a meeting. The new public trigger picker does not provide the old **Link clicked** router trigger. Choose a supported entry point instead. Use the [previous Click routing guide](https://help.distro.so/routing/click-router) to record its identity mappings, ownership priority, fallback members, distribution, event type, and after-booking actions. ## Choose the replacement | What your campaign needs | Recommended path | | --------------------------------------------------------------------- | ------------------------------------------------------------------------ | | A public reusable URL; the prospect can enter their details | Published Distro lead form with a form workflow. | | A page already has the prospect's identity and a confirmed submission | Connected external form with Explicit SDK submission. | | A personalized one-click flow without another form | A custom server-started API integration and verified scheduling handoff. | | Everyone should book one known person | A standard personal booking link. | A personal booking link does not reproduce account-owner matching or fallback distribution. ## Option 1: public lead-form link This is the simplest routed replacement. 1. Create a lead form with email, name, and any required qualification fields. 2. Create a **New form submission** workflow for it. 3. Match the prospect or company in your CRM. 4. Use the owner host source or a rulebook, with a fallback queue. 5. Add Show Scheduler, the intended event type, and Booked actions. 6. Publish the workflow, select its version in the form, and publish the form. 7. Replace the campaign destination with the form's **Hosted page**. Each visitor starts a fresh journey. The form collects identity instead of reading the old router's email/name query parameters. Do not append old Click Router parameters and assume they prefill the native form. ## Option 2: existing personalized page Use an external form connection in browser mode with **Explicit SDK submission**. After your page's own confirmed action, call the SDK with the mapped prospect fields. The workflow matches ownership and returns the scheduler through the supported browser journey. If campaign identity arrives in the URL, your application must validate and map it; the SDK does not turn arbitrary old router parameters into trusted fields automatically. Keep recipient details out of unnecessary tracking URLs. See [Form SDK](/forms/sdk.md). ## Option 3: custom one-click API journey Use **API call** when your own server resolves the recipient and starts the workflow. Your implementation must: 1. Resolve the intended prospect from a validated campaign token. 2. Send typed inputs from the server with workflow-start access. 3. Preserve a stable identity when retrying the same API event. 4. Read the run result. 5. Present scheduling through a complete compatible session handoff. 6. Handle expiry, no route, and provider failure. The API supplies a backend entry point. It does not generate a ready-made public campaign URL, and redirecting to a raw scheduler `page_url` alone does not complete the credential handoff. Use a lead form or the form SDK if you need the supported website journey without building that integration. ## Recreate ownership and distribution Match CRM records before ownership scheduling. Map CRM owners to Distro members and set an explicit fallback queue. For old strict distribution, use Pre-picked member or an earlier assignee. For flexible distribution, choose Any available member and schedule directly from the queue. Put CRM meeting actions on **Booked**. Set the booked redirect for the old confirmation destination. ## Test before changing campaign links Check an existing owner, no CRM match, an unusable owner, no available hosts, successful booking, and expiry. For personalized links, test missing or invalid identity and two different recipients. Confirm that one recipient never inherits the other's session. Old Click Router URLs do not become workflow URLs automatically. Update templates, campaigns, and website calls to action after the new journey is verified. --- # 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/click-router.md?ask=&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.