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

# Salesforce

> Connect a Business Unit to Salesforce. Events map to Campaigns, people to Contacts, and registrations to Campaign Members.

The **CRM** tab of [Developer tools](/en/developers/dev-tools) connects one Business Unit to one Salesforce org. After connecting, orriven writes:

* the event as a **Campaign**
* each person as a **Contact**
* each registration as a **Campaign Member**

[Webhooks](/en/developers/webhooks) POST events to an HTTPS endpoint. This connector writes Salesforce records with a fixed mapping.

## Who can connect

Organization **Owners and Admins** — the same permission as registering a webhook. A connection writes names, email addresses, and attendance from this Business Unit into another system. One Business Unit holds **one** CRM connection.

## Connecting

<Steps>
  <Step title="Open the drawer and choose CRM">
    The drawer's Business Unit selector sets which unit is connected.
  </Step>

  <Step title="Connect Salesforce">
    The browser opens Salesforce to sign in and authorize orriven. On return, the console shows the unit's events list and the tab shows the connection.
  </Step>

  <Step title="Confirm the connection card">
    The card shows the Salesforce org name (or its instance address), the **instance**, the time of the **last sync**, and — after consecutive errors — the number of **consecutive failures**.
  </Step>
</Steps>

<Note>
  Whether sign-in goes to Salesforce production or a **sandbox** is set per orriven deployment, not per Business Unit. To test against a sandbox before go-live, ask the platform administrator. A deployment with no Salesforce app registered shows "Not available yet" and the connect button is inactive.
</Note>

## What is synced

The mapping is fixed. People are written as **Contacts, never Leads**. Filing attendees as Leads creates duplicate Contacts.

| orriven      | Salesforce          | Fields                                                                                                                                            |
| ------------ | ------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------- |
| Event        | **Campaign**        | Name, Type `Conference`, active while the event is published, start and end dates, and a description that includes the orriven event's public id. |
| Contact      | **Contact**         | Email, first and last name (split on the first space; a single name becomes the last name). Matched on **Email**.                                 |
| Registration | **Campaign Member** | The Campaign, the Contact, and Status: `Responded` for a confirmed registration, `Sent` otherwise.                                                |

Field values are read **at sync time**, not when the event occurred. A name corrected before the sync runs is the name that is written.

## When it syncs

A sync is queued when a person is added to an event: an **attendee added from the console**, a **registration confirmed** (checkout completed or approved), or a **registration checked in** at the event door. Each queues three items in order — the Campaign, the Contact, then the Campaign Member. The Campaign Member waits for the other two instead of failing.

Orders expiring, surveys, and other event types are not synced. Only records created **after** the connection are synced. Earlier registrations are not backfilled.

## Duplicates

The same person registering for a second event — or more than once for the same event — remains **one Contact** in Salesforce, with one additional Campaign Member. Each local object maps to one Salesforce record. Salesforce's Email match is a second check.

## The sync log

Below the connection card, the tab lists recent syncs: the **object** (Campaign, Contact, Campaign member), the **subject** (the event's name or the person's email), the **Salesforce ID** once it exists, and the status — **Queued**, **Syncing**, **Synced**, or **Failed**.

A failure is retried on the same schedule as webhooks — immediately, then 1 minute, 5 minutes, 30 minutes, 2 hours, and 6 hours after the previous attempt, six attempts in all — then marked *Failed*. A failed row offers **Retry**. Failures increment the connection card's counter. The platform does not disconnect the integration.

A Salesforce error does not block or roll back the registration or checkout that queued the sync.

## Disconnecting

**Disconnect** stops further syncing. Records already written stay in Salesforce, and the existing mapping is kept, so reconnecting later does not create second copies. Connecting and disconnecting are recorded in the [audit log](/en/organization/audit-logs).

## Rules

* **One Business Unit, one connection.** The connection's scope is the unit it was made in.
* **Contacts, not Leads.** The mapping is fixed; there is no field mapper.
* **Fields are current.** Salesforce receives the value at sync time.
* **Erasure does not propagate.** A data-privacy erasure in orriven does not delete the corresponding Salesforce records. Retention in that CRM follows its own policy.
* **Not backfilled.** Only registrations after the connection are synced.

## Related

<CardGroup cols={2}>
  <Card title="Developer tools" icon="terminal" href="/en/developers/dev-tools">
    The drawer that contains the CRM tab.
  </Card>

  <Card title="Webhooks" icon="webhook" href="/en/developers/webhooks">
    HTTPS POST events, for systems other than Salesforce.
  </Card>

  <Card title="Attendees" icon="users" href="/en/events/attendees">
    Where registrations and contacts come from.
  </Card>

  <Card title="Members & roles" icon="user-shield" href="/en/organization/members-roles">
    Why connecting is Owner/Admin only.
  </Card>
</CardGroup>