> ## Documentation Index
> Fetch the complete documentation index at: https://docs.os.default.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Salesforce lead routing in Default

> How Default routes Salesforce leads, contacts, accounts, and opportunities: the triggers that start routing, the queue that picks the owner, the Owner ID write-back, and the setup it needs.

Default routes Salesforce records with a workflow. A **CRM Record Created** or **CRM Record Updated**
trigger starts the run when a record changes in Salesforce, a **Round-Robin** node picks a member from
a Default queue, and an **Update Record** node writes that member to the record's **Owner ID** field
in Salesforce.

For how the queue picks the member, see [How lead routing works](/lead-routing).

## How Salesforce lead routing works in Default

A Salesforce routing workflow in Default runs these steps:

1. **Salesforce changes a record.** A new Lead, or a change to an existing Lead, fires the workflow's
   **CRM Record Created** or **CRM Record Updated** trigger. An optional **Condition** limits which
   records qualify.
2. **The workflow picks a queue.** Set the queue in the **Round-Robin** node's **Queue** field, or pass
   in a queue that a **Match Default Record** node found earlier. To send records to different queues,
   branch with a **Multi-Branch** node and give each branch its own **Round-Robin** node.
3. **The queue's policy picks a member.** The **Round-Robin** node applies the queue's routing policy
   and makes the member available to later nodes as **Latest assigned user**.
4. **Default writes the owner back.** An **Update Record** node sets **Owner ID** on the Salesforce
   record to **Latest assigned user**. Default converts the Default user into their Salesforce user ID
   through the member's integration mapping.
5. **Default counts the assignment.** The member's round-robin count goes up, and the assignment
   appears in **Routing** under **Assignments**, on the **Object assignments** tab.

A [Rules of Engagement](/rules-of-engagement) node can take the place of steps 2 and 3: a rule chooses
the queue from the record's data, and the node selects the member. Do not add a **Round-Robin** node
after it for the same record. With it, set the owner in step 4 to **Latest resolved user**, from the
**Rules of Engagement** folder in the data picker, instead of **Latest assigned user**.

## Salesforce objects Default can route

| Salesforce object | Starts a workflow with CRM Record Created or CRM Record Updated | Owner field Default writes | Counts as a queue assignment |
| - | - | - | - |
| **Lead** | Yes | **Owner ID** (`OwnerId`) | Yes |
| **Contact** | Yes | **Owner ID** (`OwnerId`) | Yes |
| **Account** | Yes | **Owner ID** (`OwnerId`) | Yes |
| **Opportunity** | Yes | **Owner ID** (`OwnerId`) | Yes |

**Update Record** and **Create Record** can also write fields on other standard and custom Salesforce
objects. An owner written on any other object, or into a field other than **Owner ID**, does not count
toward a queue's round robin.

## Triggers that start Salesforce routing

2 workflow triggers start from a Salesforce record. Both become available once Salesforce is
connected, and both use the same fields:

| Field | What it does | Example |
| - | - | - |
| **CRM** | The connected CRM to watch. | **Salesforce** |
| **Record** | The Salesforce object to watch, such as **Lead**, **Contact**, **Account**, or **Opportunity**. | **Lead** |
| **Condition** | Optional. Only records that match start the workflow. | `Lead Source` is `Inbound` |

* **CRM Record Created** fires when a new record of that object appears in Salesforce.
* **CRM Record Updated** fires when an existing record changes. Its **Condition** can also check which
  fields changed, with the **Fields Updated** input, next to the record's values under
  **Object Fields**.

On the Salesforce integration page, **Watched fields** shows what Default monitors for each object. It
is marked **Managed by workflows**: your published workflows with these triggers set it, and the list
is read-only.

Other triggers can also route into Salesforce. A workflow that starts from a form submission, the API,
the Chrome extension, or an incoming webhook starts from the lead's data, so it checks for an existing
Salesforce record with **Match Record** first. See
[Route Salesforce leads from a form](#route-salesforce-leads-from-a-form).

## Setup for Salesforce routing in Default

Salesforce routing in Default needs 4 things in place:

| Requirement | Where | Why |
| - | - | - |
| Salesforce connected, with the Default managed package installed for all users | **Settings** → **Integrations** → **Salesforce**. See [Salesforce](/settings/integrations/salesforce). | Default reads records and writes the owner through this connection. |
| Every queue member mapped to their Salesforce User ID | Default maps members by email when Salesforce connects and when a member joins. Map anyone else in **Settings** → **Users**: open a member, select **Integrations**, and fill in the **User ID** field on the **Salesforce** card, or use the **Mappings** tab. See [Users](/settings/users). | Default converts the chosen member to a Salesforce user through this mapping. Without it, the owner write fails for that member. |
| A routing policy with **Objects** in **Assignment Units** | **Routing** → **Policies**. See [Policies](/policies). | The policy counts only the assignment units it routes. Use **Take turns equally** or **Least recent assignment**. |
| A queue that uses the policy, with active members, turned on | **Routing** → **Queues**. See [Queues](/queues). | The **Round-Robin** node picks from this queue. |

Connecting Salesforce and editing other members' mappings need admin access.

When you publish a workflow with a Salesforce trigger, Default selects the objects it needs for
Salesforce Change Data Capture, so there is no setup step in Salesforce. Salesforce limits how many
objects an org can select for Change Data Capture, and a trigger on an object past that limit can fail
to fire even though the workflow publishes. See
[How Salesforce changes reach Default](/settings/integrations/salesforce#how-salesforce-changes-reach-default).

## Build a Salesforce lead routing workflow

This example assigns every new inbound Salesforce Lead to the next member of a queue named
`Inbound Leads` and writes that member as the Lead owner.

<Steps>
  <Step title="Add the trigger">
    In **Workflows**, create a workflow and add the **CRM Record Created** trigger. Set **CRM** to
    **Salesforce** and **Record** to **Lead**.

    Optionally, add a **Condition**, for example `Lead Source` is `Inbound`.
  </Step>

  <Step title="Add the Round-Robin node">
    Select **Add Node**, then choose **Round-Robin** in the **Actions** section. Set **Queue** to
    `Inbound Leads`.
  </Step>

  <Step title="Add the Update Record node">
    Add **Update Record** from the **Records** section. Set **Platform** to **Salesforce** and
    **Record Type** to **Lead**. For **Record to update**, choose the Lead's record ID from the
    trigger.

    Under **Fields**, add **Owner ID**. For its value, open the data picker and choose
    **Latest assigned user** under **Round robin**.
  </Step>

  <Step title="Test the workflow">
    Select **Test** to open **Test Workflow**, choose the **CRM Record Created** trigger, and fill in
    the sample Lead with the email and record ID of a test Lead in Salesforce. Select **Run Test**,
    then confirm that the Lead owner changed in Salesforce.
  </Step>

  <Step title="Publish and turn it on">
    Select **Publish**. A new workflow goes live when you first publish it, so the status next to the
    switch in the top bar reads **Live** and new Salesforce Leads now run through the workflow. If the
    status reads **Paused**, turn the switch on.
  </Step>
</Steps>

<Warning>
  A workflow test performs real actions. It updates the Salesforce record and counts the routing
  assignment. Use a test Lead.
</Warning>

To send different Leads to different queues, add a **Multi-Branch** node after the trigger and give
each branch its own **Round-Robin** and **Update Record** nodes. See
[Logic and timing nodes](/workflows/steps-logic-timing#multi-branch).

## Route Salesforce leads from a form

A form submission carries the lead's form data, so the workflow checks for an existing Salesforce
record before it routes. Only new Leads get an owner, and a repeat form fill leaves the existing owner
in place:

1. Start the workflow with the **Form Submission** trigger. Set **Connected Form** to the form you
   track.
2. Add **Match Record** with **CRM** set to **Salesforce** and **Record** set to **Lead**, matched on
   email.
3. On the **No Match** branch, add **Round-Robin** to pick the owner. Then add **Create Record** with
   **Platform** set to **Salesforce** and **Record Type** set to **Lead**. In **Mapped Fields**, map
   **Email** to the email from the form, map **Last Name** and **Company**, which Salesforce requires
   on every Lead, along with any other field your org requires, and set **Owner ID** to
   **Latest assigned user**.
4. Leave the **Match** branch without an owner change, so the existing Lead keeps its owner.

**Create Record** writes only the fields in **Mapped Fields**. It does not copy the form's answers on
its own. A Lead created without **Email** gives the next form fill nothing to match, and Salesforce
rejects a Lead that is missing a required field. The run log then shows which field is missing.

Teams that do want to reroute existing Leads can add a **Round-Robin** node and an **Update Record**
node that sets **Owner ID** on the **Match** branch.

**Match Record** and **Create Record** are separate steps, so the check covers form fills that arrive
one after another. If 2 runs for the same email overlap, for example 2 form fills a second apart, both
can find no Lead and both create one. Salesforce accepts the second Lead unless a duplicate rule in
your org rejects it. When Salesforce rejects the create as a duplicate, **Create Record** logs a
warning that the Lead already exists and continues without creating one. It writes none of the mapped
fields, so that run's owner pick is not written and does not count as an assignment. To stop
overlapping fills from creating 2 Leads, add a Salesforce duplicate rule that blocks a new Lead whose
email matches an existing Lead.

**Create Record** for Salesforce also has **Update on conflict**. With it on, Default looks for a record
with the same **Match field** value and updates it instead of creating a duplicate. If more than 1
record has that value, the step fails instead of picking one, so choose a field that is unique in
your org. The update writes
only the mapped fields that Salesforce lets you change on an existing record, such as **Owner ID**.
Fields that Salesforce accepts only when it creates a record keep their current value. The lookup and
the write are separate calls too, so **Update on conflict** does not stop 2 overlapping runs from each
creating a Lead. In this pattern, **Match Record** already sends existing Leads down the **Match**
branch, so **Update on conflict** can stay off. See [CRM nodes](/workflows/steps-crm).

## Check a Salesforce routing decision

* **Runs**: open the workflow, select **Runs** in the top bar, and select a run. The **Round-Robin**
  node shows the member it assigned, and the **Update Record** node shows the fields it wrote. See
  [Run logs](/workflows/run-logs).
* **Assignments**: in **Routing**, select **Assignments**, then **Object assignments**. Each row shows
  the **Record**, **Object type**, **Assigned to**, **Queue**, and **Timestamp**. Open a row to see the
  scores behind the decision.

## Troubleshoot Salesforce routing

| What you see | What to check |
| - | - |
| **Update Record** fails because the Default user has no Salesforce integration mapping | Add the member's Salesforce User ID in **Settings** → **Users**, in the **User ID** field on the **Salesforce** card. |
| **Round-Robin** fails because the queue is not active | Turn the queue on in **Routing** → **Queues**. |
| **Round-Robin** fails because the queue has no active members | Add members to the queue, or switch existing members back on. |
| **Round-Robin** fails because the queue has no active policy | Open the queue and choose a routing policy. |
| **Round-Robin** fails because no assignee could be picked | Every active member was excluded, for example because all of them are out of office. Check the policy's **Availability** tab. |
| **Round-Robin** fails because a selected slot start is required | The policy uses **Most available calendar time**, which needs a meeting time. Switch the policy to **Take turns equally** or **Least recent assignment**. |
| The same member receives every Lead | Check that the policy includes **Objects** in **Assignment Units**, that **Owner ID** takes **Latest assigned user** from the **Round-Robin** node, and that the **Update Record** node succeeds. |
| The workflow does not start | Check that the workflow is published and its status reads **Live**, that **Record** matches the Salesforce object, and that the record meets the **Condition**. |
| A **CRM Record Updated** workflow runs again after it writes the owner | Add a **Condition** that uses **Fields Updated**, so the workflow runs only when the fields you route on change. |
| **Create Record** fails because a required field is missing | Map the field in **Mapped Fields**. A Lead always needs **Last Name** and **Company**. |
| 2 Leads exist for the same email | 2 form fills overlapped, and both runs found no Lead. Add a Salesforce duplicate rule that blocks a new Lead whose email matches an existing Lead. |
| **Create Record** shows a warning that the Lead already exists | Salesforce rejected the create as a duplicate, usually because of an overlapping run. The existing Lead was not changed. |

Related: [Lead routing software from Default](https://www.default.com/product/lead-routing-software)


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.