> 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/data-and-integrations/crm.md).

# CRM connections and identities

Connect your CRM so workflows can match existing records, preserve ownership, and write routing or booking results back.

## Connect the workspace

Open the workspace's CRM or integration settings and connect HubSpot or Salesforce using an account with the access your workflow needs.

Review the connection in the step that uses it. A resource selected from a different connection may have different fields or permissions.

Use the supported property catalogs instead of guessing API field names.

## Map connected identities

Match CRM users to the corresponding Distro members through connected identities.

This matters in both directions:

* A matched CRM owner must resolve to a Distro member to host a meeting.
* A Distro assignee must resolve to the appropriate CRM owner value for an owner update.

A CRM owner ID and a Distro member ID are not interchangeable. Check the mapping when an existing owner unexpectedly falls back to a queue.

## Choose the object and relationship

Decide whether your rule uses the contact owner, lead owner, company owner, or account owner.

For account-based routing, match the relevant company or account. For person-level routing, match the contact or lead.

A matched contact does not necessarily identify the correct account owner unless your flow reads the relevant relationship.

## Review permissions

Read steps need access to the selected records and properties. Write steps need create or update access. Activities, associations, sequencing, and lead conversion have their own requirements.

CRM trigger workflows also need event/subscription readiness. Do not assume a connected CRM starts every possible record workflow automatically.

See [Integration availability](/data-and-integrations/availability.md).

## Verify your first flow

Use a controlled existing record, a new lead, and an unmapped-owner case.

Check workflow Logs and the record in the CRM. Confirm the selected owner, mapped fields, and meeting activity.

Avoid duplicate writes from an old router and new workflow running on the same source.

See [CRM workflow steps](/workflows/crm-steps.md).


---

# 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/data-and-integrations/crm.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.
