The Salesforce connector is a built-in connector used two ways: directly in integration flows — SOQL reads as a source, record writes and batch upserts as a sink — and as the external system behind sync profiles, where it supports the full bidirectional feature set: inbound, outbound, or both with conflict detection.
Credentials and connection
The service implements Salesforce's OAuth client_credentials and legacy password grants. The current typed connection form can configure client_credentials end to end, so use that path:
- In Salesforce, create (or reuse) a Connected App with the client-credentials flow enabled, grant the API access it needs, and assign its Run As user. Capture the consumer key and consumer secret.
- Make the Run As user a dedicated integration identity with access only to the objects and fields this connection needs.
- In the owning integration app, store the consumer key and secret. Create the Salesforce REST connection with grant type
client_credentials, the correct login URL, API version, and the two${secret:...}references. - Choose Test Connection. This connector performs a real token exchange, so rejected credentials fail the test; it does not call a data endpoint, so a pass does not prove object- or field-level access. Follow with schema discovery or a safe read.
The service also accepts a raw password configuration with username and password-plus-security-token. The Web form currently shows a refresh_token choice, but the service does not accept that grant; do not select it until the form and service contract are aligned.
A revoked or expired credential is treated as a configuration fault, not a transient error: runs fail with the OAuth error text until the credential is fixed, rather than retrying forever against a locked account.
In integration flows
- Reads issue SOQL through the query API — you author the query, so any object and filter Salesforce lets that user see is available. The records collection is handed to the next step ready to map.
- Writes create, update or upsert records on any sObject, singly or in batches of up to 200 with per-record results — a failed record in a batch is reported individually rather than sinking the batch.
- Inbound keying: writing Salesforce records into xMatix with the Salesforce
Idas the external key makes re-runs update the same xMatix rows instead of duplicating them. - The classic pairing is an entity-event trigger pushing xMatix saves out to Salesforce, plus a scheduled flow polling Salesforce changes in — see outbound integration.
In sync profiles
Salesforce is the most capable sync provider, and profiles use all of it:
| Capability | What it means for you |
|---|---|
| Change feed with deletions | Deltas come from Salesforce's replication feed, which reports both modified and deleted records — so the sync can notice deletions, not just edits |
| Watermark on the system modification stamp | Changes are detected on Salesforce's system-level stamp, which also moves on automated updates — a field recalculated by Salesforce itself still syncs |
| Roughly 30-day feed depth | The replication feed only reaches back about 30 days. A profile paused longer than that reseeds the affected entities rather than silently missing the gap — expected behavior, visible on the health board |
| Keyed upsert by external id | With an external-id field on the Salesforce object holding the xMatix record id, outbound writes match-or-create in one call — re-runs cannot duplicate. Field discovery captures which field to use |
| Origin filtering | Delta reads can exclude the integration user's own writes server-side, so the engine re-reads less of its own echo |
| Batch size 200 | The ceiling per write call; larger sets are chunked automatically |
Schema discovery is live: when you declare entities and discover fields, the object and field lists come from your actual org — standard and custom objects alike, including the custom external-id field if one is deployed.
Why a dedicated integration user
Three reasons, all operational. Origin filtering keys on the acting user, so a shared Run As user would filter out human edits too. Salesforce-side audit trails show exactly what the integration changed. And that user's permissions are the integration's blast radius — scope it to the objects and fields being synced, nothing more. On the xMatix side the profile's sync identity plays the same role with the same reasoning.
Common questions
Do custom objects and fields work?
Yes. The connector is schema-agnostic: SOQL reads name whatever objects and fields you write, sinks write to any sObject, and sync-profile discovery lists your org's actual schema — custom objects, custom fields and all. The only requirement is that the integration user can see them.
What happens if someone edits the same record in both systems?
In a bidirectional profile, the conflict engine handles it: fields changed on only one side merge through, and genuinely contested fields follow the profile's conflict policy — with field-level merge, they surface as a conflict showing both values side by side for a person to decide. See sync health and conflicts.
Does deleting a record in Salesforce delete it in xMatix?
Only if you ask for that. The replication feed makes deletions visible to the sync; whether they propagate is the entity's delete-mode setting, which defaults to None. Delete-versus-edit disagreements always go to a human regardless of policy.
Sandbox or production first?
Sandbox. Point the connection's login URL at your Salesforce sandbox, run the profile until the mappings and conflict policy behave, then repoint credentials and reseed against production. The connection is the only thing that changes.