Approvals in Chatter
Approvals in Chatter is a Salesforce feature that delivers a pending approval request to the approver as a post in their Chatter feed, so they can read the record context and click Approve or Reject without opening a separate approval page.
Definition
Approvals in Chatter is a Salesforce feature that delivers a pending approval request to the approver as a post in their Chatter feed, so they can read the record context and click Approve or Reject without opening a separate approval page. When the feature is on and the request is configured for it, each newly assigned approver gets a Chatter post that shows selected fields from the submitted record, prior comments, and inline action buttons.
The feature is tied to Classic Approval Processes. You turn it on once in Setup under Chatter Settings, build an approval post template to control what the post shows, then point an approval process at that template. Salesforce now positions Flow-based approvals (built in Flow Orchestration) as the modern way to route approvals, so treat Chatter approval posts as a mature capability that pairs with the older approval engine rather than the newest option.
How an approval request reaches the feed
Turning the feature on in Chatter Settings
You enable the feature in Setup. Type Chatter Settings in Quick Find, click Edit, find the Approval Posts section, and select Allow Approvals, then save. That one switch makes approval posts possible across the org, but it does not start posting on its own. A specific approval process still has to be wired to a post template before any request shows up in a feed. Think of the Chatter Settings checkbox as the master enable and the per-process template as the thing that actually produces a post. The setting is org wide, so the decision is made once for everyone rather than per user or per object. Because the capability sits inside Classic Approval Processes, it only applies to processes built with that older approval engine. If your approvals run through Flow Orchestration instead, those routes use Flow screens and notifications and do not generate these Chatter posts. Plan the rollout knowing the switch is global but the effect is scoped to the processes and templates you actually configure.
Approval post templates control the layout
An approval post template decides what record data appears in the Chatter post. You create one in Setup under Post Templates by choosing an object, naming the template, optionally marking it as the default for that object, and selecting which fields to display. Later, when you define or edit the approval process, you associate the template with it. Without a template the request has nothing to render in the feed, so the template is a real prerequisite rather than a nice to have. Salesforce guidance suggests putting text heavy fields such as Comments or Description at the bottom of the template so the post stays readable. Keep the field list short and decision relevant. An approver scanning a feed wants the few values that drive the call, not a full record dump. A focused template with a handful of fields reads cleanly on both desktop and the Salesforce mobile app, while a long one turns the post into a wall of text that people scroll past. Templates are per object, so a multi object approval program needs one per object you approve.
Feed tracking is a quiet prerequisite
For approval posts to behave correctly, feed tracking must be enabled on the objects that your approval processes are based on. Feed tracking is the Chatter setting that lets an object have a feed at all and lets changes and posts attach to records of that object. If tracking is off for, say, the Account object, the approval post for an account record has no record feed to live in. You enable feed tracking in Setup under Feed Tracking by selecting the object and checking Enable Feed Tracking. This step is easy to forget because it lives in a different part of Setup from the approval process itself. When an approval post does not appear where you expect, feed tracking on the parent object is one of the first things to check. The requirement also means approval posts and ordinary record feed posts share the same plumbing. Turning on tracking to support approvals also turns on the general record feed for that object, which is usually fine but worth knowing before you flip it for a sensitive object.
Where the approval post shows up
A single approval request can surface in several feeds at once. The post appears in the assigned approver's own Chatter feed, in the feed of the record being approved, and in the feeds of anyone who follows that record. That last point matters for visibility and for privacy. Anyone with access to the record being approved can see the approval post in the record feed, so the post inherits the record's sharing, not some separate approval level secrecy. If the record is widely shared, the fact that it is pending approval is visible to that audience. Followers of an Opportunity or Case who watch the record for other reasons will see the approval request inline with the rest of the record activity. For approvers, this multi place visibility is a feature: a manager who already follows their team's key records sees the request without hunting for it. For administrators, it is a reminder to think about which records carry approvals and who can see them, because the approval post does not hide from people who can already open the record.
Acting on the request from the feed
When an approver clicks Approve or Reject on the Chatter post, Salesforce runs the same approval logic as the standard approval page. The decision advances the approval process, updates the underlying process instance work item, and clears the pending request from the approver's other surfaces such as the bell notifications and any Items to Approve component. The approver does not have to open the record or a separate approval screen to register the decision. Most approval posts also let the approver add a comment with the decision. That comment attaches to the approval request and lands in the approval history, so it is just as auditable as a comment typed on the standard page. Later approvers, the original submitter, and anyone reviewing the history can read it. This keeps the speed of acting in the feed from costing you the paper trail. The point of the feature is to remove a context switch. The approver is already reading the feed, the request shows up there, and one click with an optional note resolves it through the same engine that a desktop approval would use.
Opt out, email, and overlapping surfaces
Approval posts are not the only way a request reaches an approver, and users have some control. Through their personal Chatter settings, a user can opt out of receiving approval requests as posts. If they opt out, they no longer see those posts in their own feed, but they still get notified by email. Users who do not opt out generally get both the Chatter post and an email. So the same request can land as a feed post, an email through Email Approval Response, a bell notification, and an Items to Approve entry, depending on what the org has turned on. Acting in any one of these surfaces resolves the request and removes it from the rest. The redundancy is deliberate. It lets each approver work the surface that fits their habit, whether that is living in Chatter, clearing email, or scanning notifications. The trade off is feed volume. If many active approval processes all post to Chatter, busy approvers can feel spammed. The fix is usually process design and tighter templates, plus reminding people they can opt out of posts while keeping email.
Queue based approvers and high volume feeds
Approval posts are generated per assigned approver. When an approval step assigns the request to a queue rather than a single user, every member of that queue is an approver, so the post can fan out to many feeds. A large queue therefore produces a lot of feed activity for one request, which can flood the feeds of people who are only occasionally the right reviewer. This is the most common scaling complaint with the feature. It is not a defect, it is a direct result of how queue assignment and per approver posting combine. Two practical responses help. First, keep approval queues tight and role appropriate so the fan out stays small. Second, audit feed volume after launch and redesign any process that posts too often. The feature shines at moderate volume where each approver sees a manageable trickle of relevant requests. At very high volume, teams often route those approvals through email or a chat integration instead and reserve Chatter posts for the processes where in feed action genuinely speeds the team up.
Set up approval posts in Chatter
Enabling approval posts is a short Setup task, but it has three moving parts: the org switch, a post template, and feed tracking on the object. Do all three or the post will not appear. These steps cover a Classic Approval Process; Flow based approvals do not use this feature.
- Turn on approval posts
In Setup, enter Chatter Settings in Quick Find and click Edit. In the Approval Posts section, select Allow Approvals and save. This is the org wide master switch.
- Enable feed tracking on the object
In Setup, open Feed Tracking, pick each object your approval processes use, and check Enable Feed Tracking. Without a feed, the record has nowhere to show the approval post.
- Build an approval post template
In Setup, open Post Templates, click New Template, choose the object, name it, optionally mark it Default, and select the few fields the approver needs. Put text heavy fields like Comments at the bottom.
- Attach the template to the process
Open the Classic Approval Process and associate your post template with it. New requests for that process now post to the assigned approver, the record feed, and followers of the record.
The org wide switch in Chatter Settings that permits approval posts. Off by default; one setting for the whole org.
The record fields shown in the post. Keep the list short and decision relevant so the post stays readable in feed and on mobile.
Mark one template per object as the default so new approval processes on that object have a sensible post layout to start from.
Each user can opt out of approval posts in their personal settings; they keep email notifications but stop seeing the posts in their own feed.
- The feature only applies to Classic Approval Processes. Approvals built in Flow Orchestration use Flow screens and notifications, not Chatter posts.
- Forgetting feed tracking on the object is the most common reason the post never appears, because the record has no feed to host it.
- Queue based steps post to every queue member, so a large queue can flood many feeds with one request. Keep queues tight.
- Anyone with access to the approved record can see the approval post in the record feed, so the post inherits record sharing rather than hiding the approval.
Prefer this walkthrough as its own page? How to Approvals in Chatter in Salesforce, step by step
Trust & references
Cross-checked against the following references.
Straight from the source - Salesforce's reference material on Approvals in Chatter.
Hands-on resources to go deeper on Approvals in Chatter.
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 does enabling Approvals in Chatter do for approvers?
Q2. Why is Approvals in Chatter especially valuable for approvers who work primarily from mobile?
Q3. What does an approver see inside a Chatter approval post?
Discussion
Loading discussion…