Feed Item
A Feed Item is a single post in a Salesforce feed, stored as one record on the FeedItem object.
Definition
A Feed Item is a single post in a Salesforce feed, stored as one record on the FeedItem object. Each FeedItem holds one entry: a text status update, a file share, a link, a poll, a question, or an automatic post about a record-field change. The object stores the post body, the author (CreatedById), the parent record the post belongs to (ParentId), the post type (the Type field, with values like TextPost, ContentPost, LinkPost, PollPost, and TrackedChange), and counts such as LikeCount and CommentCount. FeedItem has been available in the API since version 21.0.
FeedItem is the core record behind Chatter and the feeds that appear on record pages, group pages, user profiles, and Experience Cloud sites. Comments on a post live on a separate FeedComment object, so one FeedItem can have many FeedComments. Because feeds are heavily used in active orgs, the FeedItem table often grows into millions of rows, which makes it both a rich source of engagement reporting and something admins watch for storage and retention.
How FeedItem models a Chatter post
The Type field and what each post is
The Type field tells you what kind of post a FeedItem represents, and the feed UI renders each type differently. TextPost is a plain text status update typed straight into the feed. ContentPost is a file or document share, and it points at the underlying ContentVersion through the RelatedRecordId field. LinkPost shares an external URL, storing the address and an optional title. PollPost is a multiple-choice question that members vote on. TrackedChange is an automatic post created when a tracked field on a record changes, producing entries like a stage moving from Prospecting to Negotiation. Salesforce also defines values such as AdvancedTextPost (rich-text posts created through the API) and ActivityEvent. Knowing the Type is the fastest way to separate human-authored content from system-generated activity when you report on a feed. A common analytics query groups FeedItem by Type to see how much of a feed is real conversation versus automatic record updates, which tells you whether people are actually collaborating or just watching changes scroll by.
The Parent relationship and feed visibility
Every FeedItem has a ParentId that points to the record the post belongs to. The parent can be a User (a post on someone's profile feed), a standard or custom record like an Account, Case, or Opportunity, a Chatter group, or a Topic. The parent decides where the post shows up and who can see it. A post made on an Opportunity appears in that Opportunity's feed and in the feeds of anyone following the record, and it inherits the record's sharing, so users who cannot see the Opportunity do not see the post. A post on a private group is visible only to group members. This is why so many Chatter support questions ("why can't my colleague see my post?") trace back to ParentId and the parent's access rules rather than to anything wrong with the post itself. When you query FeedItem in SOQL, filtering by ParentId is how you pull the feed for one specific record, and the CreatedById field tells you who authored each entry.
Likes, comments, and reactions
A FeedItem supports several engagement actions, and they are stored in different places. Likes are counted directly on the FeedItem through the LikeCount field, so you can sort or report on the most-liked posts without a join. Comments are not stored on FeedItem at all. They live on the separate FeedComment object, where each comment carries its own FeedItemId, body, and author. One FeedItem can have many FeedComments, and the CommentCount field on the parent post is a running tally. That split matters when you write reports or triggers, because counting comments means querying FeedComment, not FeedItem. Posts can also surface a best comment, identified by the BestCommentId field, which is useful in question-and-answer feeds where one reply is marked as the answer. If your org has enabled richer reactions beyond a simple like, those are tracked as their own records too. Treating likes, comments, and reactions as distinct objects keeps your engagement math accurate.
Feed tracking turns record changes into posts
Most automatic FeedItems come from feed tracking. When you enable tracking on an object and pick which fields to follow, Salesforce watches those fields and writes a TrackedChange FeedItem whenever one of them changes. The documentation describes it plainly: feed tracking detects changes to tracked record fields and posts them as updates in the What I Follow feed. Standard objects such as accounts, cases, contacts, leads, opportunities, tasks, and events support tracking, along with custom objects, groups, topics, and users. Some fields come pre-tracked, for example Amount, Close Date, Opportunity Name, Owner, and Stage on Opportunity. You can track up to 20 fields per object, though Activities (Task and Event) are limited to a smaller set. Configuring feed tracking requires the Customize Application permission. One quirk catches people out: changes you make to your own records show up in your profile feed but are deliberately kept out of your own What I Follow feed, so you do not get notified about your own edits.
Mentions, following, and notifications
When a FeedItem body or a FeedComment includes an @mention of a user or group, Salesforce links the mentioned party to the post and can notify them. Mentioned users find the post under feed filters like To Me and receive an in-app or email notification depending on their settings. Following is the other half of feed distribution. Users follow records, people, and topics, and the posts on anything they follow flow into their personalized feed. This following relationship, combined with ParentId, is what populates each person's feed without anyone manually sharing posts. For admins, the practical takeaway is that visibility is a product of three things working together: who authored the post, what record it is parented to, and who follows that record. When a post seems to be missing, walking through those three usually finds the answer faster than checking anything on the FeedItem record itself.
Storage, retention, and reporting
FeedItems count toward your org's data storage, and although a single post is small, volume adds up quickly in a chatty org. Salesforce also runs automatic cleanup. Tracked feed updates older than 45 days that have no likes or comments are removed and stop appearing in the feed, and the system deletes a large batch (roughly 20,000) of older tracked updates on a recurring weekly basis. Case feed items are an exception and are retained for audit and compliance purposes. Human-authored posts are not swept up by this cleanup the way stale tracked changes are, so the policy mostly trims automatic noise rather than real conversation. On the reporting side, querying FeedItem directly through SOQL or building reports on it surfaces analytics the standard feed UI never shows: posts per user, post-type mix, engagement rate, and trends over time. If auditing is enabled on a tracked field, the field's audit history survives even after the matching feed update is cleaned up, so compliance data is not lost when the feed entry disappears.
Enable Chatter feed tracking on an object
Feed tracking is what turns record changes into automatic FeedItems. Here is how an admin enables it and chooses the fields that post to feeds. You configure it once per object in Setup.
- Open Feed Tracking in Setup
In Setup, use Quick Find to open Feed Tracking. You see a list of objects on the left and the available fields for the selected object on the right.
- Enable tracking for the object
Select the object you want to track, then check Enable Feed Tracking. Until this box is checked, no field changes on that object create FeedItems.
- Pick the fields to track
Check the specific fields whose changes should post to the feed. Track only the fields that matter for collaboration so the feed is not buried in automatic updates.
- Save and verify
Save your changes, then edit a tracked field on a sample record. Confirm a TrackedChange post appears in that record's feed and in the feeds of users following it.
The per-object switch. It must be on before any field on that object generates feed posts.
The fields you select to monitor. You can track up to 20 fields per object; Activities support fewer.
Controls whether changes on related records can surface in a parent record's feed, depending on the object and edition.
- Configuring feed tracking requires the Customize Application permission, so most standard users cannot change it.
- Formula, roll-up summary, and some auto-generated fields cannot be tracked, so they will not appear in the field list.
- Changes you make to your own records post to your profile feed but are kept out of your own What I Follow feed by design.
- Tracked updates older than 45 days with no likes or comments are cleaned up automatically, except on Case records.
Trust & references
Cross-checked against the following references.
Straight from the source - Salesforce's reference material on Feed Item.
Hands-on resources to go deeper on Feed Item.
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.
Discussion
Loading discussion…