> 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/workflows/extension.md).

# Browser extension workflows

Use a Browser extension workflow for a seller-led action, such as routing a prospect to an account executive and opening scheduling.

**Admin setup comes first.** The workflow must be published, On, enabled for the workspace, and available to the caller.

## Configure the inputs

Choose **Browser extension** as the trigger. Under **Inputs**, define the values the seller needs to provide, such as email, name, company, and handoff notes.

Use supported field mappings to prefill values from stored records. A prefilled value still needs review; it may be missing or belong to a different prospect.

The trigger also provides the member who started the workflow and the source page URL.

## Build the handoff

Match the prospect in the CRM, apply ownership and distribution rules, then add **Show Scheduler**.

Use **Earlier assignee** if routing selected a person. Use a queue directly when the workflow should offer times across eligible account executives.

Map the prospect's name and email into **Booking details**. Add the seller as an attendee only if your process needs it; starting the flow does not automatically make the seller a host.

## Use the workflow

Where your installed extension exposes the new workflow action:

1. Confirm the workspace and prospect.
2. Select the approved published workflow.
3. Review and complete its inputs.
4. Start the flow and wait for its result.
5. Book through the returned scheduler using your team's approved handoff process.

The backend can return scheduling or redirect outcomes. The installed extension must support that handoff. If the workflow action is missing, ask your admin or Distro support to confirm extension compatibility.

## Sharing needs its own check

A scheduling session is specific to one run and has a booking window. A raw scheduler page URL alone does not provide a usable recipient link.

Use a share action only when your extension version supports the complete scheduling handoff. For reusable public journeys, use a [published lead form](/forms/lead-forms.md) or an appropriate [booking link](/scheduling/booking-links.md).

See [Move an Outbound Router](/migrate/outbound-router.md) for the full configuration mapping and sharing differences.

## Event-link queue behavior

The separate event-link creation path used by supported extension/API booking actions resolves a queue host using recent assignment counts, then pins the selected member to the link. It does not re-run the queue’s full routing-profile policy for every booking through that link.

Use [Outbound booking links](/guides/outbound-booking.md) and [Event-link API](/developers/event-types.md) to choose the appropriate handoff.


---

# 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/workflows/extension.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.