Send WhatsApp conversations to Salesforce from a Coexistence number

What does the n8n workflow look like?

Four nodes in a line, plus the verification branch every Meta webhook needs.

A Webhook node receives the POST that Meta sends for each message. A Salesforce node runs a SOQL query for a Lead or Contact whose phone matches the sender. An IF node splits on whether anything came back: when it did, the workflow carries the record id forward; when it did not, a Salesforce node creates a Lead with the profile name from the payload. A last Salesforce node creates a Task on that record, with the message text in the description and the subject saying it was a WhatsApp message.

The verification branch answers Meta's GET with the hub.challenge value as a plain body. Without it Meta never starts delivering, and the rest of the workflow sits idle.

Task or note: which should hold the message?

A Task, for most teams, because it lands in the activity timeline that sales reps already read and can be reported on. Set its status to completed so it does not appear as an open to-do, and give it a subject that names the channel, so a filter on WhatsApp activity is a single condition.

The n8n node's Add note operation suits a different case: a summary rather than every message. Some teams have the workflow collect a day's messages per contact and write one note in the evening, which keeps the timeline readable for a customer who sends twenty short lines.

Whichever you pick, write the WhatsApp message id into the record. Meta retries deliveries, and a workflow that checks for an existing id before writing never logs the same message twice.

Can the team still answer from the phone, and will Salesforce see it?

Yes to both. Coexistence keeps the WhatsApp Business app working on the same number, so the people who answered customers yesterday keep doing so. When they reply from the app, Meta sends an echo of the outgoing message to the same webhook destination, under the smb_message_echoes field.

Add a second path in the workflow for those echoes and log them as outgoing Tasks. A rep who opens the lead then sees both the question and the answer the shop gave, in order, without anyone copying a chat by hand.

Replies the workflow sends itself, through an HTTP Request node against the Cloud API, should be logged at the moment of sending. The workflow already has the text and the record id in hand.

How do you avoid duplicate leads?

Match on a normalised phone number, not on the field as people typed it. Meta sends the sender as digits with the country code and no plus sign. Salesforce phone fields hold whatever the person who created the record entered, with spaces, brackets and dashes.

The dependable approach is a custom text field holding the digits-only number, filled by the workflow when it creates a lead and by a backfill for existing records. The SOQL query then compares that field for equality, which is fast and exact.

Check contacts as well as leads. A customer who already converted is a Contact, and a workflow that only searches leads will create a fresh lead for every existing customer who writes in.

Common mistakes

• Searching only the Lead object. Existing customers are Contacts, and each one who writes in becomes a duplicate lead.
• Logging messages as open Tasks. Reps get a to-do for every customer line; set the status to completed when creating them.
• Skipping the verification GET branch in the workflow. Meta never confirms the destination, and no message is ever delivered.

Frequently asked questions

Keep reading