Twilio and Salesforce, logged on the record.
Sending a message is the easy part. Knowing it was delivered, who replied, whether they had consented, and having all of it visible on the contact is where these projects take their time.
Why the stock connector isn’t the end of it.
Most Twilio and Salesforce work starts as a small request: let reps text customers. The messaging itself is a few API calls. What turns it into a project is everything around it — inbound replies landing on the right record, delivery and failure status being visible, opt-outs being honoured permanently, and the whole thing standing up to a compliance question a year later.
There is also a regulatory dimension that is not optional. In the US, A2P 10DLC registration governs application-to-person messaging on standard numbers, and unregistered traffic is filtered or blocked by carriers. It is paperwork rather than engineering, but it determines whether anything you build actually reaches a handset.
Where it breaks.
Each of these is something we have had to unpick on live systems.
Inbound replies have nowhere to land
Outbound is trivial; inbound is where the design lives. A reply arrives as a webhook carrying a phone number, and matching that to the right Lead, Contact or Person Account is genuinely ambiguous when the same number appears on several records. Without a matching strategy, replies land in a log nobody reads.
Opt-out has to be permanent and global
Twilio honours STOP at the messaging-service level, but Salesforce does not know it happened unless you write it back. If the opt-out is not recorded on the record, the next campaign re-adds the contact and you are sending to someone who explicitly refused — which is both a compliance failure and a trust one.
Delivery status is not send confirmation
The API accepting a message means Twilio queued it, not that it arrived. Delivered, undelivered and failed all arrive later on a status callback. Teams that treat the initial response as success end up believing customers were contacted when carriers silently dropped the traffic.
10DLC registration gates everything
Unregistered A2P traffic on a standard US long code gets filtered heavily. Registration involves the brand, the campaign and the use case, and it takes real calendar time. It needs to start early, because no amount of engineering compensates for messages carriers refuse to deliver.
WhatsApp is a different product with different rules
WhatsApp requires pre-approved templates for business-initiated messages and enforces a 24-hour customer service window for free-form replies. Building it as though it were SMS with a different channel flag produces messages that are rejected at the template check rather than delivered.
How we approach it.
We define the record-matching rule before writing any messaging code, because it determines the data model. Usually that means a normalised phone field with a single owner, plus a defined resolution order when a number matches more than one record.
Consent and opt-out are stored on the Salesforce record, not left implicit in Twilio. That way a rep can see the state, campaigns can filter on it, and a compliance question a year later has an answer with a timestamp attached.
Delivery status callbacks are wired in from the start and surfaced on the activity record, so a failed message is visible to the person who sent it rather than discovered when a customer says they never heard from you.
Questions people actually ask.
For application-to-person SMS to US numbers on standard long codes, yes. Unregistered traffic is filtered or blocked outright by the carriers. Registration covers the brand and the campaign, takes real calendar time, and should be started well before you need the messaging live.
By matching the inbound number against a normalised phone field, with an agreed resolution order when several records share a number — common with shared business lines. We define that rule during design, because leaving it to chance means replies land somewhere nobody looks.
Yes, though it behaves differently. Business-initiated WhatsApp messages need templates approved in advance, and free-form replies are only permitted inside a 24-hour window after the customer's last message. That shapes the workflow, so it is a design decision rather than a channel toggle.
It handles the messaging transport well. What it does not decide for you is record matching, consent storage, or how delivery failures become visible to the people who need to act on them. Those are the parts that determine whether the system is trusted internally.