Send leads to Salesforce
A chat lead becomes a record on the Salesforce object you choose.
Salesforce is the one connection here with four values instead of one, and every one of them is a value you make once in Salesforce itself. There is no sign-in button: a connected app issues a refresh token, and this route trades that token for a short-lived one on every call.
What you need
A connected app, in Salesforce Setup, with OAuth enabled and two scopes:
api-- read the objects and their fields, and create the record.refresh_token-- keep working without somebody signing in again every hour.
From it you need three things: the consumer key, the consumer secret (both under Manage consumer details) and a refresh token, which the app's OAuth flow issues the first time somebody authorises it.
Production or sandbox
The fourth value. A sandbox does not log in at login.salesforce.com; it logs in at test.salesforce.com, and a sandbox refresh token presented to the production host is refused with the same message as a revoked one. Pick the right one on the connect screen and that whole class of confusion disappears.
You do not need to give us an instance URL. Salesforce returns it with the short-lived token, and every call is built from what it returned -- which is also why a connection that works today keeps working if your org is migrated.
Connect and route
- In Destinations, connect Salesforce with the four values.
- Pick the object. Lead, Contact, Account, Opportunity and Case come first; everything else your org exposes is under Other objects and Custom objects.
- Create a route -- which leads it takes, and which object they become.
- Map the fields. They are read from your org's own describe, so what you see is what your admin created, with the picklist values they actually allow.
What gets sent
Only fields Salesforce says are createable, which is why an id, a formula or a rollup never appears in the mapper: they would fail every lead.
Values are shaped per field type. A picklist has to match one of its own values -- a near miss is left out rather than sent, because a rejected value fails the whole record. A multi-select picklist is joined with semicolons, which is what Salesforce stores. A checkbox reads yes, no, true, false, 1 and 0. A date becomes YYYY-MM-DD.
A Lead needs a last name and a company. Salesforce refuses one without either, and the refusal names the API field rather than the label somebody mapped. Both are filled in from what the lead carries when the mapping leaves them out, so a route is never one missing field away from losing every lead.
What it does not do
It creates. It does not update an existing record, and it does not run your duplicate rules for you -- your org's rules apply to this insert exactly as they would to any other. Matching an existing record means deciding which field is the identity, and that is a setting we would rather ask for than guess.