> 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/guides/mql-handoff.md).

# MQL to SQL handoff

Route a marketing-qualified lead to sales the moment it qualifies, and follow up if the rep doesn't act.

A marketing-qualified lead (MQL) is a lead marketing judges ready for sales. A sales-qualified lead (SQL) is one a rep has reviewed and accepted. Distro runs the handoff: when a lead reaches MQL, the workflow fills gaps, picks a rep, writes the owner, and tells the rep. The rep then accepts or rejects the lead in the CRM.

## At a glance

| Step            | Workflow step                                     | What it does                           |
| --------------- | ------------------------------------------------- | -------------------------------------- |
| 1. Detect       | **Salesforce object updated**                     | Starts when `Status` changes to `MQL`. |
| 2. Fill gaps    | **Enrich Lead**                                   | Adds title and company size.           |
| 3. Pick the rep | **Assign from Queue** or **Apply Rulebook**       | Chooses the SDR.                       |
| 4. Own          | **Update Salesforce Record**                      | Writes the owner and a handoff status. |
| 5. Tell         | **Notify in Slack**                               | Messages the rep.                      |
| 6. Follow up    | **Wait**, **Match Salesforce Record**, **Branch** | Escalates if the rep hasn't acted.     |

## Start once per MQL

**Salesforce object updated** checks **Start only when** against the record after each change. Set it to `Status` **Equals** `MQL`, with `Status` under **Fields to include**. The workflow's first write sets `Status` to `Assigned`, so the lead no longer matches: later edits start no run, and the workflow's own write doesn't start it again. A lead that leaves MQL and comes back starts a new run.

{% hint style="warning" %}
Write the handoff status early. Until the status moves off `MQL`, every edit to the lead matches **Start only when** and can start another run.
{% endhint %}

A lead *created* at MQL fires **Salesforce object created**, so build a twin workflow on that trigger if forms or imports create MQLs.

## Build the workflow

{% stepper %}
{% step %}

### Trigger on the status change

Choose **Salesforce object updated**, object `Lead`, with the **Start only when** condition above.
{% endstep %}

{% step %}

### Enrich and pick the rep

Add **Enrich Lead** with the lead's email, then **Assign from Queue** with `Inbound SDRs`.
{% endstep %}

{% step %}

### Write the owner and mark the handoff

Add **Update Salesforce Record** for the trigger's lead: `OwnerId` from the assignee, `Status` set to `Assigned`.
{% endstep %}

{% step %}

### Tell the rep

Add **Notify in Slack** to the **Earlier assignee** and, for a team record, your MQL channel. Include the lead's name, company, and enriched details.
{% endstep %}

{% step %}

### Follow up if the rep doesn't act

Add **Wait** (for example 4 hours), **Match Salesforce Record** on `Lead` by `Id`, and **Branch** where the matched `Status` still equals `Assigned`. On that branch, message the manager, or assign again from another queue.
{% endstep %}
{% endstepper %}

To route by territory or segment, use **Apply Rulebook** after **Enrich Lead** so rules can read the enriched size. Write the **Rulebook owner** on **Resolved**, and send **Else** to a catch-all queue with its own owner write and alert.

## HubSpot differences

|                    | Salesforce                                                                       | HubSpot                                                                                         |
| ------------------ | -------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------- |
| Trigger            | **Salesforce object updated**, `Lead`                                            | **Hubspot record updated**, Contact, **Only when selected properties change**: `lifecyclestage` |
| MQL value          | `Status` = `MQL`                                                                 | `lifecyclestage` = `marketingqualifiedlead`                                                     |
| Owner field        | `OwnerId`                                                                        | `Contact owner`                                                                                 |
| How changes arrive | Polling every minute, or **Instant Salesforce updates** with Change Data Capture | Polling every few minutes                                                                       |

## MQL by score

* **The CRM keeps the score**: a small workflow on the score field sets `Status` to `MQL` when the score is at least your threshold; that starts the handoff.
* **Marketo keeps the score**: a Marketo campaign calls a Distro webhook. See [Marketo](/guides/marketo.md).
* **Distro scores the lead**: see [Fit score](/routing/fit-score.md).

## Accept or reject

The SQL decision lives on the CRM record, so conversion reports use CRM data. To act on rejections, build a workflow on the status changing to your rejected value, for example to post to marketing ops or start a nurture sequence.

## Troubleshoot

| What you see                          | What to check                                                                                 |
| ------------------------------------- | --------------------------------------------------------------------------------------------- |
| The same lead is routed on every edit | The workflow doesn't move `Status` off `MQL`, so later edits still match **Start only when**. |
| A lead set to MQL starts no run       | The workflow is **Off**, or the lead was created at MQL.                                      |
| The owner write fails                 | Map the rep's Salesforce user under **Connected identities**.                                 |
| The lead is routed twice              | Another workflow also routes MQLs. Keep one owner of the motion.                              |


---

# 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/guides/mql-handoff.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.