> 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/outbound-router.md). # Move an Outbound Router Recreate a seller-led handoff with a **Browser extension** workflow. The seller provides the prospect details, the workflow chooses the receiving teammate, and scheduling completes the meeting. Start from the [previous Outbound Routers guide](https://help.distro.so/routing/outbound-routing/routers) and your current sales handoff process. ## Before you start Record allowed bookers, form fields and defaults, CRM prefill, ownership priority, fallback participants, event type, attendance, owner updates, and sharing modes. Confirm that your installed extension supports the new workflow start and complete scheduling handoff. The workflow backend alone does not establish extension compatibility. ## 1. Replace the outbound form with trigger inputs Create a workflow with **Browser extension**. Declare the input fields the seller needs: prospect email, name, company, qualification values, and handoff notes. Use supported mappings for record prefill. Review old booker-only and locked-field behavior separately; the workflow inputs are not an automatic import of the old outbound form. Keep the prospect identity distinct from the member who starts the flow. ## 2. Recreate receiving-team routing Create the receiving team's profile and queue. Use CRM matching followed by a rulebook when account owners take priority. Set a fallback for new prospects and unusable owners. For a simple pool, schedule directly from the queue. For an explicit owner assignment, use Assign from Queue or Apply Rulebook, then schedule with **Earlier assignee**. ``` Browser extension → Match CRM record → Ownership / qualification decision Existing owner → Show Scheduler: CRM record owner New qualified lead → Show Scheduler: AE queue Not ready → Notify or create a follow-up task ``` Connect lookup errors separately from No match. ## 3. Choose the event and attendees Select the old handoff's event type in Show Scheduler, or recreate it first. Map the prospect's name, email, and notes into **Booking details**. Configure required and optional attendees. If the SDR should attend, add the appropriate seller reference where the attendee field supports it. Do not assume the member starting the workflow is invited automatically. Required attendees limit the available times. Optional attendees receive the invite without their calendars limiting the scheduler. ## 4. Recreate CRM writes and alerts Update ownership at the stage your process needs. Flexible scheduling only knows its final host after Booked. Put meeting activities and booking alerts on **Booked**. Use **Not booked** for a task, notification, or supported sequence follow-up. Review existing event messages to avoid sending duplicate alerts. ## 5. Review booker access Use workflow **Access** for the supported editing restrictions and workspace sharing controls for the permissions they expose. Do not treat an editor list as a replacement for the old allowed-booker list. Confirm the caller's workflow-start permission and actual extension access with a representative seller. ## 6. Publish and test the seller experience Validate, simulate, publish, and turn the workflow On. Then start it through the actual extension with controlled details. Confirm the prospect, selected owner, available slots, host, attendees, CRM write, and messages. ## Sharing differences | Old capability | What to use or verify | | -------------------------------- | ---------------------------------------------------------------------------------------------------------- | | Book a meeting now | Start the supported extension workflow and use its returned scheduler. | | Recipient-specific prepared link | Requires a sharing surface that creates the complete session handoff; a raw scheduler URL is insufficient. | | Reusable routed link | Use a published lead form when each recipient should begin a new qualified journey. | | Magic Slots / proposed times | A separate offer-times capability; not created by adding Show Scheduler. | | Prepared-link expiry of days | Different from a workflow scheduler's 3–60 minute booking window. | | Old reusable URLs | Must be replaced or explicitly supported by the transition plan. | Do not advertise old sharing options until they are verified in the new surface your team uses. For a public campaign journey, follow [Move a Click Router](/migrate/click-router.md). For the final rollout, use the [Migration checklist](/migrate/checklist.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/migrate/outbound-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.