> 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/account-owners.md). # Send leads to the account owner Send new leads from accounts you already work to the account owner, and everyone else to a queue. Account-based routing gives a new lead from a company you already work to the rep who owns that account, so one rep works each account. People from companies you don't work yet go to a queue as usual. ## At a glance | Step | Workflow step | What it does | | ------------------- | -------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------ | | 1. Start | **Salesforce object created** or **New form submission** | One run per new lead or form fill. | | 2. Find the account | **Match Salesforce Record** on `Account` | Finds the account for the lead's company. | | 3. Matched | **Update Salesforce Record**, or **Apply Rulebook** | Writes the account owner as the lead owner. **Convert Salesforce Lead** can merge the lead into the account. | | 4. Everyone else | **Assign from Queue** | Picks the next rep. | ## Two ways to give matched leads to the owner | | Copy the owner | Route with a rulebook | | ----------------- | ----------------------------------------------------------------------- | ------------------------------------------------------------------------------------ | | How | **Update Salesforce Record** sets `OwnerId` to the account's `OwnerId`. | An **Existing account owner** rule routes to the owner field, with a fallback queue. | | Owner mapping | Not needed: the Salesforce user ID is written as is. | Needed under **Connected identities**; an unmapped owner counts as empty. | | Owner who left | Not checked, unless the match excludes them. | The rule's fallback applies. | | Where it's logged | The run in **History** | The run and the rulebook's **Logs** | Neither path takes a queue turn. A rule's fallback queue pick does. ## Build it with Salesforce {% stepper %} {% step %} ### Start on new inbound leads Choose **Salesforce object created** with `Lead`, include `Email` and `LeadSource`, and set **Start only when** `LeadSource` **Equals** `Inbound`. {% endstep %} {% step %} ### Match the account Add **Match Salesforce Record** on `Account`. Under **Matching criteria**, map `Website` to the lead company's **Domain** (Distro takes it from the lead's email and ignores personal domains), and `OwnerId` to `queue:account-executives`. That keeps only accounts owned by a current member of that queue; integration users and reps who left take **Not matched**. Under **When several records match, pick**, choose **Highest value of a field** with `NumberOfEmployees`. {% hint style="warning" %} Matching compares values exactly, so keep account websites as bare domains or match on a domain field you maintain. {% endhint %} {% endstep %} {% step %} ### Give matched leads to the owner On **Matched**, add **Update Salesforce Record** for the trigger's lead with `OwnerId` set to the account's `OwnerId`. To turn the lead into a contact on that account, add **Convert Salesforce Lead** with the account as **Existing account**; conversion is permanent. {% endstep %} {% step %} ### Assign everyone else On **Not matched**, add **Assign from Queue** with `Inbound AEs`, then **Update Salesforce Record** with `OwnerId` set to the assignee. {% endstep %} {% step %} ### Test and publish **Simulate** with a lead whose domain belongs to a test account, then **Publish** and turn it **On**. {% endstep %} {% endstepper %} ## Route with a rulebook instead A rulebook puts the owner and your territories in one ordered list. See [Create a rulebook](/routing/rulebooks.md). 1. Add the Salesforce account as a source. Its fields become available in conditions and as owner targets. 2. Add a rule `Existing account owner`: the owner field **Is present**, route to that owner, fallback to `Named Accounts`. Keep it at the top, then publish. 3. In the workflow, connect both outcomes of the account match to **Apply Rulebook**. On **Not matched** the owner input is empty, so territory rules decide. 4. On **Resolved**, write `OwnerId` from the **Rulebook owner**. On **Else**, assign from a catch-all queue. ## Route target accounts differently | Goal | Where to put the condition | | ---------------------------------------------------------------- | -------------------------------------------------------------------------------------- | | Only target accounts go to their owner | Add your target field to **Matching criteria**, for example `Target__c` equals `true`. | | Target accounts get an extra alert | **Branch** on **Matched**, for example tier **Is one of** `Tier 1`. | | Target accounts whose owner can't take it go to a strategic team | A rule below `Existing account owner` that routes the tier to `Strategic Accounts`. | ## HubSpot differences * Match **Company** on `Company Domain Name`, which is stored as a bare domain, and write `Contact owner`. * A HubSpot company can have no owner. Add a `Company owner` presence condition so unowned companies take **Not matched**. * Link the contact to the company with **Create HubSpot Association**, or use **Match by association** when the contact is already linked. ## Troubleshoot | What you see | What to check | | --------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------- | | A lead from a known account goes to the queue | The account's `Website` isn't the bare domain, the lead used a personal email, or the owner isn't an active, mapped member of the queue in `OwnerId`. | | The wrong account's owner gets it | Set **When several records match, pick**. | | The owner write fails | The owner is a deactivated Salesforce user. The `queue:` criterion keeps their accounts out. | | **Convert Salesforce Lead** fails | Check the connected user's permissions and your duplicate rules. | --- # 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/account-owners.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.