Chatlet
A Chatlet is an informal, unofficial nickname that circulated in the early Salesforce Chatter community for a small custom add-on bolted onto the Chatter publisher, the composer box at the top of a feed where people write posts.
Definition
A Chatlet is an informal, unofficial nickname that circulated in the early Salesforce Chatter community for a small custom add-on bolted onto the Chatter publisher, the composer box at the top of a feed where people write posts. The idea was a compact widget that let users create a specialised post type, such as a quick poll or a recognition shout-out, instead of plain text. The word was never a Salesforce product name. It does not appear in any official Help article, Developer Guide, or release note.
Because Salesforce never shipped a feature called Chatlet, the term is best treated as legacy shorthand. The capabilities people described as Chatlets are delivered today by documented mechanisms: Quick Actions (also called publisher actions) for declarative post types, and Rich Publisher Apps for programmatic add-ons built with Lightning components. If you find Chatlet in an old blog or forum thread, read it as one of those supported features rather than a thing you can switch on in Setup.
How Chatter publisher add-ons actually work
Where the word came from
Chatter launched in 2010 as Salesforce's enterprise collaboration feed. The publisher, the box where you compose a post, was extensible from early on, and the community reached for catchy names to describe the small custom buttons that admins and partners added to it. Chatlet was one of those names, riffing on the diminutive of Chatter, in the same spirit as applet or widget. It implied a tiny app living inside the feed. The problem is that Salesforce never adopted the word. Search the official documentation and you will not find it in any Help topic, Developer Guide, Trailhead module, or release note. The supported vocabulary was always different: publisher actions, Quick Actions, and later Rich Publisher Apps. So Chatlet is a piece of folklore rather than a feature. Knowing the history matters because the underlying need was real. Teams wanted more than plain text in the feed. They wanted polls, structured questions, and peer recognition. Salesforce answered that need, just under different names, and those names are the ones you configure and search for today.
Quick Actions: the declarative answer
The standard, no-code way to extend the Chatter publisher is a Quick Action, historically labelled a publisher action. A Quick Action puts a button in the publisher that opens a small form, captures a few fields, and creates a record or a post without leaving the feed. Salesforce ships several standard ones out of the box. Post writes a text update. Poll lets people vote on options. Question posts a structured question that supports a Best Answer. Thanks records peer recognition with a badge. Each of these is exactly the kind of compact, single-purpose interaction the Chatlet nickname tried to capture, and each is fully documented. Admins control which actions appear in the publisher through the global publisher layout and through object page layouts. You can also build your own object-specific or global Quick Actions that prefill fields, target a particular record, or launch a screen. Because Quick Actions are point-and-click, they cover most feed-extension requirements without a single line of code, which is why Salesforce steered admins toward them and why the informal Chatlet idea never needed to become a real product.
Rich Publisher Apps: the programmatic answer
When a Quick Action form is not enough, the supported path is a Rich Publisher App. This is the documented Salesforce mechanism for attaching a custom payload to a feed item using Lightning components. A Rich Publisher App has two halves. A composition component implements the lightning:availableForChatterExtensionComposer interface and renders the custom input experience inside the publisher. A rendering component implements lightning:availableForChatterExtensionRenderer and draws the resulting payload when the post appears in the feed. The two communicate through the lightning:sendChatterExtensionPayload event, which hands the composed data off to the feed item. Salesforce caps the publisher at five Rich Publisher Apps, so the surface stays usable rather than crowded. This is the closest thing to a true micro-app inside Chatter, and it is the architecture the Chatlet idea was reaching for years before the framework existed. If a partner once shipped a custom poll or survey button for the feed, a modern rebuild would almost certainly be a Rich Publisher App on Aura, configured per Experience Cloud site or internal org.
The publisher and feed components
On a Lightning record page, the publisher is not magic. It is a component you can place and configure. The forceChatter:publisher component is a standalone publisher you drop onto a page, and it works alongside the forceChatter:feed component, which renders the feed itself. Splitting them gives you freedom in how you arrange the page, and the link between the two is automatic, requiring no extra code. The publisher exposes a context attribute that decides which feed it talks to: set it to RECORD for a record feed, or GLOBAL for other feed types such as the company-wide feed. This component model is what an admin or developer touches when building a custom feed experience in the Lightning App Builder. It is also the surface a Rich Publisher App plugs into. None of this uses the Chatlet vocabulary, which is precisely the point. The real building blocks have specific, searchable names. When someone hands you a requirement framed as adding a Chatlet, the practical translation is choosing between a Quick Action, a Rich Publisher App, or a custom component on the feed page, depending on how much custom behaviour the requirement demands.
A worked example: the recognition button
Picture a request that an old document calls a Thanks Chatlet, a button so people can thank a colleague in the feed. There are three honest ways to deliver it, and none of them is a Chatlet. The simplest is the standard Thanks action. If Work.com style recognition is enabled, Thanks already exists as a publisher action that posts a badge to the recipient, so the task is just adding it to the right publisher layout. The second route is a custom Quick Action: build an action on a custom recognition object, prefill the giver and date, and let the user pick a recipient and a message. That stays declarative and is easy to maintain. The third route, for a branded recognition experience with images and animation, is a Rich Publisher App. You write a composition component for the giver to choose a badge and a renderer to display it inline in the feed, wired together with the payload event. The decision tree is always the same. Reach for the standard action first, a custom Quick Action next, and a Rich Publisher App only when the interaction genuinely needs custom Lightning UI.
Why no feature ever carried the name
Salesforce had good reasons not to formalise a Chatlet feature. A single named widget type would have competed with the action framework the platform was already standardising. Quick Actions gave admins one consistent model for buttons everywhere, on records, on the Home page, in the utility bar, and in the publisher, so inventing a separate feed-only widget would have fragmented that story. On the programmatic side, the company invested in Lightning components and then in the Rich Publisher Apps interfaces, which let any custom experience live in the feed without a bespoke product surface. The result is that the feed-extension need was met by general-purpose frameworks rather than a narrow feature. That is usually better for customers, because the same skills carry across the platform. It does leave a vocabulary gap, which is how informal words like Chatlet fill in. For a dictionary, the useful service is to name that gap plainly. There is no Chatlet object, no Chatlet setup node, and no Chatlet API. There are actions and Rich Publisher Apps, and those are what you configure, document, and troubleshoot.
How to read Chatlet in old material
Plenty of pre-2018 partner blogs, idea posts, and informal slide decks use Chatlet loosely, and you may still meet it in a handover document or a long-lived knowledge base. The safe reading is to map it to a supported concept rather than to go hunting for a setting that does not exist. If the context is a poll, a question, or a recognition post, the modern equivalent is a standard or custom Quick Action. If the context is a richer custom experience embedded in the feed, the equivalent is a Rich Publisher App built on Lightning components. If the context is the feed surface itself, think forceChatter:publisher and forceChatter:feed on a Lightning page. Treat any claim that Chatlet is a first-class Salesforce feature as inaccurate, because the official documentation has never described one. This matters for estimates and design reviews. A stakeholder who believes Chatlets exist may expect a toggle in Setup, when the real work is configuring an action or, in the harder case, writing and deploying a couple of Aura components. Naming the gap up front keeps the conversation grounded in what the platform actually supports.
Trust & references
Cross-checked against the following references.
Straight from the source - Salesforce's reference material on Chatlet.
Hands-on resources to go deeper on Chatlet.
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. In early Chatter, where did a Chatlet appear for users to interact with?
Q2. Which modern Salesforce feature absorbed the question-asking Chatlet pattern?
Q3. How should you treat the term Chatlet when reading a 2014 partner blog post?
Discussion
Loading discussion…