Messaging Components
A Messaging Component is a reusable, configurable block of structured content that Salesforce sends inside a Messaging for In-App and Web conversation.
Definition
A Messaging Component is a reusable, configurable block of structured content that Salesforce sends inside a Messaging for In-App and Web conversation. Instead of plain text, a component can be a tappable button set, a selectable list, a date and time picker, a secure form, an enhanced link, a payment request, or an authentication prompt. Salesforce calls these Interactive Messaging Components, and an admin builds them once in the Messaging Component Builder, then reuses them across enhanced channels.
Each component is rendered into the format that the customer's channel understands. The same List Picker shows one way in Enhanced Chat and another way on Enhanced WhatsApp, because Salesforce maps the component to a channel-native format behind the scenes. Components can be sent by a human agent from the conversation window, returned automatically by a flow or Einstein Bot, or pushed through the Messaging API, so the rich experience does not depend on per-channel rendering code.
How Messaging Components fit into enhanced channels
What counts as a component
Salesforce groups the building blocks under Interactive Messaging Components. The library you build from includes the Enhanced Link, a Question with static options, a Question with dynamic options, the Time Selector, the Auto-Response, the Secure Form, the Authentication Request, the Payment Request, and the option to share an External App. A Question is the type most people picture when they think of buttons or a list, because it presents choices the customer taps rather than types. Each component is created and named once, then referenced wherever you need it. The static-option version hardcodes the choices at design time. The dynamic-option version fills the choices at send time, so a list of open cases or available appointment slots can be built from live data. Picking the right type up front matters, because not every type is available on every channel. The Messaging Component Types and Formats page in Salesforce Help is the table you check before committing to a component for a given channel, since it lists which formats each enhanced channel supports.
The Messaging Component Builder
Admins assemble components in the Messaging Component Builder, a point-and-click tool in Setup. You choose a component type, then fill in its fields through the properties panel on the right side of the builder. Fields that accept dynamic values carry a type of Template, which is where formula templates come in. The builder lets you test a draft directly in an Enhanced Chat session before you expose it to customers, so you can see how a Question or a Secure Form actually renders without waiting for a real conversation. Because a component is metadata, it can move between orgs through your normal deployment process and be referenced by automation once it exists. The builder also handles images: you can attach a static image to a component, or supply an image dynamically so the picture changes per customer. Building components here, rather than hand-coding payloads, is what keeps the same definition consistent across every channel that supports it.
Channel-aware rendering
Enhanced channels each speak their own message format, so Salesforce translates a single component into the shape the channel expects. The supported enhanced channels include Enhanced Chat, Messaging for Web, Messaging for In-App, Enhanced WhatsApp, and Enhanced Messaging for SMS. A Question renders as quick-reply buttons or a list on chat-style channels, while on Enhanced WhatsApp it maps to WhatsApp's own interactive message format. Some components have no equivalent on a particular channel, which is why the formats reference exists and why you test before you ship. WhatsApp adds a wrinkle worth knowing: because WhatsApp requires pre-approved templates for business-initiated messages, Salesforce supports connecting a component to a WhatsApp message template through an External Template format. That lets an admin reuse an approved template inside the component framework instead of maintaining a separate path. The practical rule is simple. Build the component once, then confirm the rendering on each channel you actually use.
Dynamic content with formula templates
Static text only goes so far, so component fields of type Template accept a formula template that resolves when the message is sent. You write the template with parameter references that pull from the conversation context, most often the Messaging Session object and the related Messaging End User. A greeting can read something like Hi there {!$Parameters.MessagingSession.MessagingEndUser.Name}, my name is {!$Parameters.MessagingSession.LastModifiedBy.FirstName}. For richer cases, sObject formulas let a component reference fields from a related record, so an order summary or case detail can be assembled from real data rather than typed out. Salesforce documents a set of supported functions you can use inside these formulas, which keeps the templates predictable. Formula templates are common in auto-responses tied to events like Start Conversation, End Conversation, and Inactive Conversation, where the same component fires for many customers but each person sees their own name and details. This is the mechanism that makes a single component feel personalized at scale.
Who sends components, and how
There are three paths a component can travel. A human agent can send one from the conversation window during a live messaging session, picking the component and filling any open fields before sending it to the customer. A flow can return a component automatically, which is how a screen flow drives a Time Selector to collect a preferred appointment slot, or how an auto-response greets a customer the moment a conversation starts. Einstein Bots and Agentforce service agents return components as part of their replies, so a bot can present a Question or a Secure Form instead of only typing words. The Messaging API exposes components to custom integrations too. Because the same component definition feeds all three paths, you do not rebuild the experience for each one. An admin defines the Time Selector once, and the agent console, the flow, and the bot all reference the identical component, which keeps behavior and branding consistent no matter who or what sends it.
Translation and localization
Customer-facing text inside a component can be translated so a global audience reads messages in its own language. Button labels, question prompts, and form field text are all candidates for localization. Salesforce supports translating components and also offers real-time translation for service messaging, each with its own considerations and limits that the Help docs spell out. The reason this lives at the component level is that a single Question or Secure Form may be sent to customers across many locales, and you do not want to clone the component once per language. Translate the user-facing strings, and the customer sees the variant that matches their language while the underlying component stays one definition. Plan translation early, because adding it after a component is live across several channels means re-testing each rendering. If you skip translation, customers simply see the default-language text, which is fine for a single-locale deployment but a poor experience for an international one.
Considerations before you rely on one
Components are powerful, but they come with rules. Channel support is the first one: a component that works in Enhanced Chat may have no equivalent on another channel, so the Messaging Component Types and Formats and the Considerations pages are required reading before a production rollout. Dynamic options depend on the data you feed them, so a poorly scoped query can return too many or too few choices. Formula templates only support a documented set of functions, so test that your formula resolves rather than assuming it will. WhatsApp's template approval process means an External Template component cannot be changed freely once approved on the WhatsApp side. Channel platforms also evolve independently of Salesforce releases, so a component that renders cleanly today can need a tweak after a WhatsApp or web client update. The safe habit is to build the component, test it on every channel you use, document which channels each component is approved for, and schedule periodic re-testing so a silent channel change does not break a customer-facing flow.
How to build and send a Messaging Component
Build a reusable Interactive Messaging Component in the Messaging Component Builder, then send it from an agent conversation, a flow, or a bot in your enhanced channels. The example below creates a Question with static options, the type most teams start with.
- Open the Messaging Component Builder
In Setup, find the Messaging Components area and create a new component. Give it a clear name you will recognize when an agent, flow, or bot references it later.
- Choose the component type
Select a type such as a Question with static options. Use the formats reference to confirm the type is supported on the enhanced channels you plan to use before you go further.
- Fill in the fields and any dynamic content
Use the properties panel on the right to set the prompt text and the choices. For fields of type Template, write a formula template that references the Messaging Session or Messaging End User so the message personalizes at send time.
- Test in an Enhanced Chat session
Run the component in a test Enhanced Chat session to see the rendering. Repeat the check on each other channel you support, since the same component looks different per channel.
- Save and reference it
Save the component, then point an agent quick action, a flow, an auto-response, or an Einstein Bot dialogue at it so it can be sent in real conversations.
The internal label used to find and reference the component from agents, flows, and bots.
The kind of component, for example a Question, Time Selector, Secure Form, or Enhanced Link, which determines the format and channel support.
The prompt, options, or fields the customer sees. Static values are set here directly; dynamic values use a Template field with a formula template.
- Not every component type is supported on every channel. Check the Messaging Component Types and Formats page before committing a component to a channel.
- Dynamic options are only as good as the data behind them. Scope the source so the customer sees a usable number of choices, not hundreds.
- Formula templates support only documented functions. Test that the template resolves in an Enhanced Chat session instead of assuming the syntax is valid.
- An Enhanced WhatsApp component that uses an External Template depends on a WhatsApp-approved template, so it cannot be edited freely after approval.
Prefer this walkthrough as its own page? How to Messaging Components in Salesforce, step by step
Trust & references
Cross-checked against the following references.
- Interactive Messaging ComponentsSalesforce
- Messaging Component Types and FormatsSalesforce
Straight from the source - Salesforce's reference material on Messaging Components.
Hands-on resources to go deeper on Messaging Components.
About the Author
Dipojjal Chakrabarti is a B2C Solution Architect with 29 Salesforce certifications and over 13 years in the Salesforce ecosystem. He runs salesforcedictionary.com to help admins, developers, architects, and cert/interview candidates sharpen their fundamentals. More about Dipojjal.
Test your knowledge
Q1. What are Messaging Components used to build inside a customer messaging conversation?
Q2. How does the platform handle a Messaging Component when the conversation runs on different channels?
Q3. Which item belongs in the standard Messaging Components library?
Discussion
Loading discussion…