Two-Way SMS Inside Salesforce, Built With Apex, LWC and an SMS Provider API

#The situation this design answers

Text messages get read. For appointment confirmations, quick questions, quote follow-ups and reminders, a text often gets a reply in minutes where an email waits for days. So staff text customers, and very often they do it from their own phones.

That creates a gap the business cannot see. The conversation that settled an appointment time or answered a pricing question lives on one person's phone. The CRM shows nothing. When that person is away, nobody else can pick up the thread. When they leave, the history goes with them. And there is no consistent handling of customers who ask not to be texted.

Our team has built SMS systems inside Salesforce with custom Apex, Lightning Web Components and REST-based integrations, including with TextBolt. This study brings that work together around a common situation: a service business that wants two-way texting on the customer record, available to the whole team and governed by the same rules as everything else in the CRM.

#What we build

01 A conversation view on the record

A Lightning Web Component on the contact, lead or case shows the text conversation like a messaging app: messages in order, outbound and inbound clearly separated. Staff can reply directly from the record. Anyone on the team can see the full history.

02 Templates with merge fields

Common messages, such as appointment confirmations or quote follow-ups, are available as templates that pull in the customer's name, appointment time or quote details. Staff save time and messages stay consistent.

03 Sending through an SMS provider API

When a user sends a message, Apex calls the SMS provider's REST API, such as TextBolt, and stores the outbound message on the record with its status. The provider handles delivery; Salesforce holds the record.

04 Receiving replies with an Apex REST endpoint

Replies arrive at an Apex REST endpoint in Salesforce. The endpoint normalizes the sender's number, matches it to the right contact or lead and adds the message to the conversation. Replies that cannot be matched are flagged so a person can link them, instead of disappearing.

05 Consent and opt-out handling

Opt-out keywords in a reply update the customer's consent automatically. Every outbound send, manual or automated, checks consent before it goes. Customers who ask to stop receiving texts are respected without anyone having to remember.

06 Automation with Flow

Flow can send automated texts, such as appointment reminders or follow-ups after a quote, using the same templates, the same sending path and the same consent checks as manual messages.

#A conversation, end to end

A customer requests a quote through the website. The next morning, a team member opens the lead in Salesforce and sends a short text from the conversation view, using a template that includes the customer's name. The message goes out through the SMS provider and appears on the record.

The customer replies an hour later with a question about timing. The reply reaches the Apex endpoint, is matched to the lead by phone number and appears in the conversation. A different team member, covering that afternoon, sees the whole exchange and answers.

The day before the agreed appointment, a Flow sends an automated reminder. The customer replies "STOP" because they no longer want texts. Their consent updates automatically, and no further texts will be sent to them, manual or automated.

#Why inbound matching is the hardest part

Sending a text from Salesforce is straightforward. Receiving the reply and putting it in the right place is where most SMS projects struggle.

Phone numbers are stored inconsistently: with or without country codes, spaces or leading zeros. The same number can appear on several records, such as a contact and an older lead. Customers sometimes reply from a different number. A reliable design normalizes numbers on both sides, uses the most recent conversation to choose between duplicates, and flags anything ambiguous for a person instead of guessing. That is what turns texting from a convenience into a dependable part of the customer record.

#Why build it with Apex and LWC

There are good packaged SMS apps for Salesforce, and for many teams they are the right answer. Custom Apex and Lightning Web Components make sense when the business needs texting to follow its own rules: a particular conversation layout on a particular record, templates tied to specific data, consent rules that match its compliance obligations, or automation that a package does not support.

Building it this way also keeps the integration transparent. The sending logic, the inbound endpoint and the matching rules are code the business owns and can test alongside the rest of its org, instead of behavior hidden inside a package.

#Templates, timing and tone

Text messages are short, personal and arrive on the device people carry everywhere. That makes them effective, and it makes mistakes more noticeable than in email.

Keep templates short and specific. A good text says who it is from, why it is being sent and what the customer should do next, in a sentence or two. Templates are written with that discipline, and merge fields fill in the details that make each one personal.

Respect the clock. Automated texts are scheduled for reasonable hours in the customer's time zone. A reminder at an unsociable hour undoes the goodwill the channel creates.

Identify the business. Customers should never wonder who is texting them. Messages make the sender clear, especially the first message in a conversation.

Make replies welcome. Two-way texting only works if customers know they can reply. Messages are written to invite a response where one is useful, and the conversation view makes sure someone sees it.

Know when to switch channels. Some conversations outgrow a text, such as detailed quotes or sensitive matters. Staff can move the conversation to a call or email, and the text history remains on the record for context.

Getting these details right is what turns a technical integration into a channel customers appreciate rather than tolerate.

#How we deliver SMS in Salesforce, end to end

Decide build or buy first. We compare packaged options with a custom build against the business's real requirements before writing code.

Design consent up front. Opt-out handling and send checks are designed before any message is sent.

Normalize and match. Phone number handling and inbound matching are specified and tested with realistic, messy data.

Build the conversation view for staff. The component is designed to make texting from Salesforce easier than texting from a phone.

Automate last. Automated texts are added once manual texting works, using the same rules.

#The decisions that matter

The record is the home of the conversation. Every message, in and out, is stored where the team can see it.

Consent is enforced by the system. People should not have to remember who opted out.

Ambiguity goes to a person. Unmatched replies are flagged, never guessed.

#What changes

#What we would tell a team considering SMS in Salesforce

Get the conversations off personal phones and onto the record. Decide honestly whether a package fits or a custom build is needed, design consent before you send a single message, and spend your engineering effort on matching replies to the right customer. Do that, and texting becomes one of the most responsive and best-recorded channels your team has.