> ## 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.

# HubSpot lead routing in Default

> How Default routes HubSpot contacts, companies, and deals: the triggers that start routing, the queue that picks the owner, the HubSpot owner write-back, and the setup it needs.

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

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

## How HubSpot lead routing works in Default

A HubSpot routing workflow in Default runs these steps:

1. **HubSpot changes a record.** A new contact, or a change to an existing contact, 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 the owner property
   (`hubspot_owner_id`) on the HubSpot record to **Latest assigned user**. Default converts the Default
   user into their HubSpot owner 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**.

## HubSpot objects Default can route

| HubSpot object | Starts a workflow with CRM Record Created or CRM Record Updated | Owner property Default writes | Counts as a queue assignment |
| - | - | - | - |
| **Contact** | Yes | **Contact owner** (`hubspot_owner_id`) | Yes |
| **Company** | Yes | **Company owner** (`hubspot_owner_id`) | Yes |
| **Deal** | Yes | **Deal owner** (`hubspot_owner_id`) | Yes |

An owner written on any other HubSpot object, or into a property other than `hubspot_owner_id`, does
not count toward a queue's round robin.

## Triggers that start HubSpot routing

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

| Field | What it does | Example |
| - | - | - |
| **CRM** | The connected CRM to watch. | **HubSpot** |
| **Record** | The HubSpot object to watch: **Contact**, **Company**, or **Deal**. | **Contact** |
| **Condition** | Optional. Only records that match start the workflow. | `Country/Region` is `Germany` |

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

On the HubSpot 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 HubSpot. 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
HubSpot record with **Match Record** first. See
[Route new HubSpot contacts from a form](#route-new-hubspot-contacts-from-a-form).

## Setup for HubSpot routing in Default

HubSpot routing in Default needs 4 things in place:

| Requirement | Where | Why |
| - | - | - |
| HubSpot connected | **Settings** → **Integrations** → **HubSpot**. See [HubSpot](/settings/integrations/hubspot). | Default reads records and writes the owner through this connection. |
| Every queue member mapped to their HubSpot Owner ID | Default maps members by email when HubSpot connects and when a member joins. Map anyone else in **Settings** → **Users**: open a member, select **Integrations**, and fill in the **Owner ID** field on the **HubSpot** card, or use the **Mappings** tab. See [Users](/settings/users). | Default converts the chosen member to a HubSpot owner 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 HubSpot and editing other members' mappings need admin access.

## Build a HubSpot lead routing workflow

This example assigns every new HubSpot contact to the next member of a queue named `Inbound Routing` and
writes that member as the contact owner.

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

    Optionally, add a **Condition** on a contact property, for example the contact's country.
  </Step>

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

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

    Under **Fields**, add **Contact owner**. 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 contact with the email and record ID of a test contact in HubSpot. Select
    **Run Test**, then confirm that the contact owner changed in HubSpot.
  </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 HubSpot contacts 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 HubSpot record and counts the routing
  assignment. Use a test contact.
</Warning>

To send different contacts 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 new HubSpot contacts from a form

A form submission carries the lead's form data, so the workflow checks for an existing HubSpot contact
before it routes. Only new contacts get an owner, and a repeat form fill leaves the existing owner in
place. HubSpot's **Create Record** has no **Update on conflict** option, so this check is also what
keeps a repeat form fill from creating a second contact:

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 **HubSpot** and **Record** set to **Contact**, matched on
   email.
3. On the **No Match** branch, add **Round-Robin** to pick the owner. Then add **Create Record** with
   **Platform** set to **HubSpot** and **Record Type** set to **Contact**. In **Mapped Fields**, map
   **Email** to the email from the form, map any other answers you want on the contact, such as the
   first and last name, and set **Contact owner** to **Latest assigned user**.
4. Leave the **Match** branch without an owner change, so the existing contact keeps its owner.

**Create Record** writes only the properties in **Mapped Fields**. It does not copy the form's answers
on its own. A contact created without **Email** gives the next form fill nothing to match, so that
fill creates another contact.

Teams that do want to reroute existing contacts can add a **Round-Robin** node and an **Update Record**
node that sets **Contact owner** 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 contact and both try to create one. HubSpot keeps a contact's email unique, so it rejects
the second create. **Create Record** then logs a warning that the record already exists. When
HubSpot's message names the existing contact's ID, the step continues with that ID. When it names
no ID, the step's ID is empty, so find the contact with a **Match Record** on **Email** if later nodes
need it. Either way the step writes none of its mapped properties, so the second run's owner pick is
not written to the contact and does not count as an assignment.

If a workflow also writes the same pick to the contact's company, for example after a **Match Record**
with **Match by association** turned on, each owner write counts as its own assignment. The member's
count then goes up by 2 for 1 lead. See [CRM nodes](/workflows/steps-crm).

## Routing controls Default applies to HubSpot records

Before Default writes a HubSpot owner, the queue's routing policy applies these controls:

| Control | What it does | Where to set it |
| - | - | - |
| Distribution rule | **Take turns equally** or **Least recent assignment** picks the next member. | Policy, **Assignment** tab |
| Weighted distribution | Gives members larger or smaller shares, based on each member's weight. | Policy, **Assignment** tab, and the queue's members |
| Tiebreaker | **Recency** or **Random** decides between tied members. | Policy, **Assignment** tab |
| Out-of-office and busy exclusions | Skips members who are out of office (on by default). Can also skip members who are busy on their calendar or about to be out of office. | Policy, **Availability** tab |
| Assignment reset schedule | Clears counts **Monthly** or **Quarterly**, or **Never**. | Policy, **Assignment** tab |
| Calibration | Adjusts 1 member's count, for example for a new member. | The queue's members |
| Assignment record | Saves each decision with the scores behind it and the policy version used. | **Routing** → **Assignments** |

See [How lead routing works](/lead-routing) for how these controls combine.

## Check a HubSpot 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 properties 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 HubSpot routing

| What you see | What to check |
| - | - |
| **Update Record** fails because the Default user has no HubSpot integration mapping | Add the member's HubSpot Owner ID in **Settings** → **Users**, in the **Owner ID** field on the **HubSpot** 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 contact | Check that the policy includes **Objects** in **Assignment Units**, that the owner property 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 HubSpot 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 properties you route on change. |
| A repeat form fill creates a second contact | Check that **Create Record** maps **Email** from the form, so **Match Record** can find the contact next time. |
| **Create Record** shows a warning that the record already exists | HubSpot rejected the create because another record already has a value that must be unique, usually the email after an overlapping run, or a unique custom property you mapped. Nothing was written. Check which property the warning names. If the step's ID is empty, find the contact with a **Match Record** before later nodes use it. |

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.