# Salesforce Destination Config Reference


> Complete Rudder CLI reference for the Salesforce destination config keys, authentication, record mapping, source types, and secrets.



[Salesforce](https://www.rudderstack.com/docs/destinations/streaming-destinations/salesforce/setup-guide/) is a CRM destination. RudderStack creates and updates Salesforce leads — or other Salesforce objects — from `identify` events, from its servers.

In a Salesforce destination spec:

- `type: salesforce`
- `definition_version: 1`

**Warning:** RudderStack has deprecated this destination in favor of [Salesforce v2](https://www.rudderstack.com/docs/destinations/streaming-destinations/salesforce-v2/), which Rudder CLI doesn't support.

## Sample configuration

```yaml
version: rudder/v1
kind: destination
metadata:
  name: salesforce-prod
spec:
  id: salesforce-prod
  display_name: Salesforce Production
  type: salesforce
  definition_version: 1
  enabled: true
  config:
    user_name: "{{ .SALESFORCE_USER_NAME }}"
    password: "{{ .SALESFORCE_PASSWORD }}"
    initial_access_token: "{{ .SALESFORCE_SECURITY_TOKEN }}"
    sandbox: false

    map_properties: true
    use_contact_id: false

    connection_mode:
      web: cloud
      cloud: cloud
    consent_management:
      web:
        - provider: oneTrust
          consents:
            - marketing
```

The above example signs in to a production org. `initial_access_token` holds the user's security token, not an access token — see [Authentication](#authentication).

## Config keys

`config` accepts only the keys listed below. The [shared config key rules](https://www.rudderstack.com/docs/rudder-cli/destination-types/#config-key-rules) cover unknown keys, defaults, and immutability.

**Info:** Salesforce accepts only `identify` events. RudderStack doesn't deliver any other event type to it. See [Send events to Salesforce in cloud mode](https://www.rudderstack.com/docs/destinations/streaming-destinations/salesforce/cloud-mode/).

### Authentication

RudderStack signs in as a Salesforce user through the OAuth 2.0 username-password flow, which your org must allow. It sends `password` with `initial_access_token` appended, as Salesforce expects for API sign-ins. See [Connection settings](https://www.rudderstack.com/docs/destinations/streaming-destinations/salesforce/setup-guide/#connection-settings).

<div class="rs-ckeys">
<div class="rs-ckey" id="user_name">
  <div class="rs-ckey__title">
    <p class="rs-ckey__name">user_name</p>RequiredSecret</div>
  <p class="rs-ckey__field">
    Type:
    <code>string</code>
  </p>
<p class="rs-ckey__field">
  Description:
  Username of the Salesforce user RudderStack signs in as.
</p>

<div class="rs-ckey__notes">
  <p class="rs-ckey__field">Notes:</p>
  <ul>
<li>At most 100 characters, and must not contain line breaks.</li>
<li>A <code>{{ path || fallback }}</code> template is accepted in place of a literal.</li>
</ul>

</div>

<div class="rs-ckey__extra">
  Supply it as a <code>{{ .VAR }}</code> reference rather than a literal — see <a href="#secrets" >Secrets</a>.
</div>

</div>

<div class="rs-ckey" id="password">
  <div class="rs-ckey__title">
    <p class="rs-ckey__name">password</p>RequiredSecret</div>
  <p class="rs-ckey__field">
    Type:
    <code>string</code>
  </p>
<p class="rs-ckey__field">
  Description:
  Password of that user.
</p>

<div class="rs-ckey__notes">
  <p class="rs-ckey__field">Notes:</p>
  <ul>
<li>At most 100 characters, and must not contain line breaks.</li>
</ul>

</div>

<div class="rs-ckey__extra">
  Supply it as a <code>{{ .VAR }}</code> reference rather than a literal — see <a href="#secrets" >Secrets</a>.
</div>

</div>

<div class="rs-ckey" id="initial_access_token">
  <div class="rs-ckey__title">
    <p class="rs-ckey__name">initial_access_token</p>RequiredSecret</div>
  <p class="rs-ckey__field">
    Type:
    <code>string</code>
  </p>
<p class="rs-ckey__field">
  Description:
  The user&rsquo;s Salesforce security token.
</p>

<div class="rs-ckey__notes">
  <p class="rs-ckey__field">Notes:</p>
  <ul>
<li>At most 100 characters, and must not contain line breaks.</li>
<li>A spec that omits this key fails validation with <code>'initial_access_token' is required</code>.</li>
</ul>

</div>

<div class="rs-ckey__extra">
  <p><strong>Warning:</strong> Despite its name, this key holds the user's <strong>security token</strong> — the dashboard calls it <strong>Security Token</strong> — not an OAuth access token. Salesforce issues it to the user, and RudderStack appends it to <code>password</code> to sign in.</p>
<p>Supply it as a <code>{{ .VAR }}</code> reference rather than a literal — see <a href="#secrets" >Secrets</a>.</p>

</div>

</div>

<div class="rs-ckey" id="sandbox">
  <div class="rs-ckey__title">
    <p class="rs-ckey__name">sandbox</p></div>
  <p class="rs-ckey__field">
    Type:
    <code>boolean</code>
  </p><p class="rs-ckey__field">
    Default value:
    <code>false</code>
  </p>
<p class="rs-ckey__field">
  Description:
  Sign in to a Salesforce sandbox through <code>test.salesforce.com</code> instead of a production org through <code>login.salesforce.com</code>. The dashboard calls it <strong>Sandbox mode</strong>.
</p>

<div class="rs-ckey__extra">
  Developer instances aren&rsquo;t supported — see <a href="https://www.rudderstack.com/docs/destinations/streaming-destinations/salesforce/setup-guide/#does-rudderstack-support-dev-instances-of-salesforce" >Does RudderStack support dev instances of Salesforce?</a>.
</div>

</div>

</div>

### Record mapping

Without an external ID naming a Salesforce object, RudderStack looks the lead up by the event's email and updates it, or creates a lead when none matches. An `identify` event without an email then fails. See [Update Salesforce objects](https://www.rudderstack.com/docs/destinations/streaming-destinations/salesforce/cloud-mode/#update-salesforce-objects).

<div class="rs-ckeys">
<div class="rs-ckey" id="map_properties">
  <div class="rs-ckey__title">
    <p class="rs-ckey__name">map_properties</p></div>
  <p class="rs-ckey__field">
    Type:
    <code>boolean</code>
  </p><p class="rs-ckey__field">
    Default value:
    <code>true</code>
  </p>
<p class="rs-ckey__field">
  Description:
  Map traits onto standard Lead and Contact fields, such as <code>firstName</code> to <code>FirstName</code>, and send other traits to custom fields named after them with a <code>__c</code> suffix. Other Salesforce objects receive traits as they are. The dashboard calls it <strong>Map Rudder Properties to Salesforce Properties</strong>.
</p>

<div class="rs-ckey__extra">
  <p><strong>Warning:</strong> RudderStack doesn't read this key for this destination, and always maps. Setting <code>map_properties</code> to <code>false</code> has no effect.</p>
<p>See <a href="https://www.rudderstack.com/docs/destinations/streaming-destinations/salesforce/cloud-mode/#update-custom-fields" >Update custom fields</a> and <a href="https://www.rudderstack.com/docs/destinations/streaming-destinations/salesforce/cloud-mode/#supported-mappings" >Supported mappings</a>.</p>

</div>

</div>

<div class="rs-ckey" id="use_contact_id">
  <div class="rs-ckey__title">
    <p class="rs-ckey__name">use_contact_id</p></div>
  <p class="rs-ckey__field">
    Type:
    <code>boolean</code>
  </p><p class="rs-ckey__field">
    Default value:
    <code>false</code>
  </p>
<p class="rs-ckey__field">
  Description:
  When the lead matching the event&rsquo;s email has been converted, update the contact it was converted to instead of the lead. The dashboard calls it <strong>Use contactId for converted leads</strong>, and suggests turning it on when your lead and contact field mappings are the same.
</p>

</div>

</div>

### Per-source keys

Both keys are objects keyed by the local source type — the tokens listed under [Source types](#source-types). A key naming a source type this destination doesn't support fails validation.

<div class="rs-ckeys">
<div class="rs-ckey" id="connection_mode">
  <div class="rs-ckey__title">
    <p class="rs-ckey__name">connection_mode</p></div>
  <p class="rs-ckey__field">
    Type:
    <code>object</code>
  </p>
<p class="rs-ckey__field">
  Description:
  Maps each source type you connect to the mode its events reach Salesforce in, using the modes in <a href="#source-types" >Source types</a>.
</p>

<div class="rs-ckey__notes">
  <p class="rs-ckey__field">Notes:</p>
  <ul>
<li>An entry is required for each source type you connect — see <a href="#connect-a-source" >Connect a source</a>.</li>
</ul>

</div>

<div class="rs-ckey__extra">
  <div class="rs-code">
  <div class="rs-code__head">yaml<button class="rs-code__copy" type="button">
      
      Copy
    </button>
  </div>
  <div class="highlight"><pre class="chroma"><code class="language-yaml" data-lang="yaml">connection_mode:
  web: cloud
  cloud: cloud</code></pre></div>
</div>
</div>

</div>

<div class="rs-ckey" id="consent_management">
  <div class="rs-ckey__title">
    <p class="rs-ckey__name">consent_management</p></div>
  <p class="rs-ckey__field">
    Type:
    <code>object</code>
  </p>
<p class="rs-ckey__field">
  Description:
  Consent provider configuration per source type. The entry shape, accepted providers, and the rules on <code>resolution_strategy</code> and <code>consents</code> are shared across all destination types — see <a href="https://www.rudderstack.com/docs/rudder-cli/destination-types/#consent-management" >Consent management</a>.
</p>

</div>

</div>

## Source types

Salesforce accepts events from these source types in the mentioned connection modes:

| Source type | Connection mode |
| :-----| :-----|
| `android` | `cloud` |
| `android_kotlin` | `cloud` |
| `ios` | `cloud` |
| `ios_swift` | `cloud` |
| `web` | `cloud` |
| `unity` | `cloud` |
| `react_native` | `cloud` |
| `flutter` | `cloud` |
| `cordova` | `cloud` |
| `cloud` | `cloud` |
| `warehouse` | `cloud` |

Every source type is `cloud` only — events reach Salesforce from RudderStack's servers, never in device mode.

`warehouse` is the token a [Reverse ETL source](https://www.rudderstack.com/docs/sources/reverse-etl/) resolves to. Rudder CLI manages the destination’s `warehouse` entry — if the destination is connected to a Reverse ETL source, set `connection_mode.warehouse: cloud` in its spec, or `apply` removes it.

Rudder CLI can also declare the Reverse ETL connection itself, for the types listed under [Supported destinations](https://www.rudderstack.com/docs/rudder-cli/yaml-retl-connections/#supported-destinations) — see [Manage Reverse ETL Connections using Rudder CLI](https://www.rudderstack.com/docs/rudder-cli/retl-connections/).

**Info:** The dashboard additionally offers Salesforce to AMP and Shopify sources. Rudder CLI doesn&#39;t manage those connections, so `amp` and `shopify` are invalid here.

## Connect a source

An event stream connection to this destination is checked against two rules at `validate` time.

**The source's type must be supported.** A source's type resolves to one of the tokens above before the check — a JavaScript source resolves to `web`, and webhook and server-side SDK sources resolve to `cloud`. Every type an event stream source can resolve to is supported here, so this check always passes.

**The destination config must carry a `connection_mode` entry for that source type.** This lives on the destination spec, not on the [connection spec](https://www.rudderstack.com/docs/rudder-cli/yaml-connections/). Without it:

```text
destination 'salesforce-prod' config has no 'connection_mode' entry for source type 'web'
```

Salesforce needs no additional config keys to connect a source of any type.

## Secrets

`user_name`, `password`, and `initial_access_token` are the secret keys. Write each as a `{{ .VAR }}` reference and supply the value at apply time:

```yaml
config:
  user_name: "{{ .SALESFORCE_USER_NAME }}"
  password: "{{ .SALESFORCE_PASSWORD }}"
  initial_access_token: "{{ .SALESFORCE_SECURITY_TOKEN }}"
```

```bash
export RUDDER_SALESFORCE_USER_NAME="..."
export RUDDER_SALESFORCE_PASSWORD="..."
export RUDDER_SALESFORCE_SECURITY_TOKEN="..."
rudder-cli apply

# or
rudder-cli apply --var-file secrets.vars.yaml
```

Note that:

- `rudder-cli import` writes only the secrets the API returns, as `{{ .VAR }}` references, and leaves the others out. Add any secret key it leaves out, then supply the variables before you apply — see [Secrets](https://www.rudderstack.com/docs/rudder-cli/destination-types/#secrets).

See [How to Use Variable Substitution in Rudder CLI](https://www.rudderstack.com/docs/rudder-cli/variable-substitution/).

## Changes by release

<p>No changes since this type became available.</p>

For changes across every destination type, see [Destination Type Changes by Release](https://www.rudderstack.com/docs/rudder-cli/destination-types/changes/).

## See more

- [Salesforce Setup Guide](https://www.rudderstack.com/docs/destinations/streaming-destinations/salesforce/setup-guide/) for the API user, the username-password flow, and supported editions
- [Destination Type Reference for Rudder CLI](https://www.rudderstack.com/docs/rudder-cli/destination-types/) for the rules shared across destination types
- [Destination YAML Reference](https://www.rudderstack.com/docs/rudder-cli/yaml-destinations/) for the spec envelope