Comment
A comment in Salesforce is a free-text note attached to a parent record.
Definition
A comment in Salesforce is a free-text note attached to a parent record. It captures updates, decisions, and back-and-forth that do not fit neatly into a structured field. Salesforce ships several comment-style objects rather than one universal type. The most used are CaseComment (notes on a Case) and FeedComment (replies under a Chatter post or feed item). Each comment stores the author, the timestamp, the body text, and a reference to its parent.
Comments hold the conversational layer of CRM work. A Case's structured fields say what happened; its comments say why it happened, what the agent tried, and what the customer asked for. That narrative is what the next person reading the record relies on. Because the pattern (free text plus author plus parent) is so common, Salesforce repeats it across Cases, Chatter feeds, and older products like Ideas and Solutions.
How comments work across Salesforce objects
CaseComment, the most common comment object
CaseComment is the standard object for notes added to a Case. Each record links to its Case through the ParentId field, holds the text in CommentBody, and tracks CreatedById and CreatedDate automatically. The CommentBody field accepts up to 4,000 characters of plain text, which is plenty for a status update or a summary of a customer call. Agents add comments throughout the life of a Case to record what they tried, what the customer said, and what comes next. A single complex Case can collect dozens of comments before it closes. CaseComment supports the standard create, query, and delete calls, so you can read and write comments through the API, Apex, and Flow. It does not support update on published comments in the usual way, which protects the customer-facing record. In Lightning Experience, comments surface in the Case feed and in the Case Comments related list, depending on how the page is built. Reporting on CaseComment lets you measure agent activity, such as comment volume per agent and the time between case creation and the first comment.
Public versus internal comments
The IsPublished field on CaseComment decides who can see the note. When IsPublished is false, the comment is internal and stays inside the org. When it is true, the comment becomes customer-facing. Published comments can appear in an Experience Cloud site and can be included in case notification emails sent to the contact. This single flag is one of the most consequential choices an agent makes on a Case. Mark a private troubleshooting note as published by mistake and the customer reads internal language never meant for them. That kind of slip turns into a compliance finding in regulated industries. Many service teams handle the risk with page layouts and validation that default new comments to private, then require a deliberate action to publish. Training also helps, since the field reads as a simple checkbox but carries real weight. When you build automation that inserts CaseComment records, set IsPublished explicitly rather than relying on the default, so the visibility is never left to chance.
FeedComment for Chatter and record feeds
FeedComment is the comment object for Chatter, available since API version 18.0. Each FeedComment attaches to a parent feed item through FeedItemId and carries the body text, the author, and the timestamp. These are the replies you see threaded under a Chatter post, whether the post sits on a user profile, a group, or a record like an Account or Opportunity. FeedComment supports a CommentType value, with TextComment for ordinary replies and ContentComment for replies that carry an attached file. A key behavior sets FeedComment apart from a normal record: published comments cannot be edited. You can delete a FeedComment, but you cannot change its text after the fact, which keeps the feed honest as a record of what was actually said. FeedComment supports rich text and @mentions, so a reply can format text and tag a colleague at the same time. Tagging someone fires a notification, and that notification is one of the strongest drivers of cross-team collaboration on the platform. Reporting on FeedComment underpins adoption and engagement dashboards for Chatter.
Comment objects on older products
Several comment objects exist mainly for backward compatibility. IdeaComment belongs to the Ideas product, where community members commented on submitted ideas. Solution review comments belonged to Solutions, the older knowledge feature that predates Salesforce Knowledge. Both Ideas and Solutions are legacy, and Salesforce steers new work toward newer features. The modern equivalents lean on FeedComment or on a custom comment object built for the replacement product. If you inherit an org that still runs Ideas or Solutions, you may find these comment records in reports and SOQL, and they keep working for existing data. The lesson for a new build is to reach for the current comment surface first. For collaboration on any record, Chatter and FeedComment are the standard answer. For knowledge, Salesforce Knowledge articles replace Solutions. Treat the legacy comment objects as something to migrate away from rather than something to extend, and check the release notes before assuming a legacy product still receives investment.
Comments versus structured fields
Comments and fields solve different problems, and mixing them up causes pain later. A comment is free text meant for humans to read in context. A field is structured data meant for filtering, rollups, and reports. The instinct to drop a number or a status into a comment is understandable in the moment, but it traps that value in prose that no report can aggregate. If you ever want to count, group, or chart something, it belongs in a field, not a comment. A practical pattern keeps both: capture the structured facts in fields such as Status, Priority, and a resolution picklist, then use comments for the story that surrounds those facts. Reports then read the fields, while the comments give a human the full picture when they open the record. This split also keeps comment text shorter and more useful, because agents are not trying to encode data into sentences. When you design a new object, decide up front which information is structured and which is narrative, and you avoid a cleanup project down the road.
Storage, retention, and large feeds
Comments accumulate, and at scale that matters. A busy support org generates thousands of CaseComment records a week, and a popular Chatter post can gather hundreds of FeedComment replies. Each record consumes data storage like any other row, so high-volume orgs should treat comment growth as a planning item, not an afterthought. There is no separate, cheaper storage tier for comments. If old comments are no longer needed for reference or compliance, an archival policy can move or delete them to keep storage in check. Be careful with deletion, since comments are often part of the audit narrative on a Case, and removing them can erase context that an auditor or a future agent needs. A safer approach exports comment history to an archive before any purge. Watch the parent object too, because deleting a Case cascades to its comments, and deleting a feed item removes its FeedComments. Plan retention at the parent level, and the comments follow the same lifecycle without surprises.
Common pitfalls with comments
Three problems show up again and again. The first is the accidental publish. An agent sets CaseComment.IsPublished to true on a note that contained internal pricing or a candid remark, and the customer sees it. Defaulting comments to private and requiring a deliberate publish step is the usual guard. The second is treating comments as a database. Teams that cram serial numbers, dates, or statuses into comment text find that none of it reports cleanly, and they end up rebuilding the data into fields anyway. Decide early what is structured. The third is unbounded growth. Comments are easy to create and easy to forget, so storage creeps up quietly until a large org notices the bill. A retention policy and periodic archival keep it predictable. A smaller fourth issue is expecting to edit a published FeedComment. You cannot, so people delete and re-post, which can confuse a thread. Knowing the edit rule up front saves that confusion and keeps the feed readable.
Set up Case Comments on the Case page
Most teams want agents to add Case Comments quickly from the Case page without leaving the Service Console. You do that by adding the Case Comment action to the page and confirming the related list is present. This setup is done in Setup by an admin, not in the API.
- Open the Case page layout or Lightning record page
In Setup, go to Object Manager, choose Case, then open Page Layouts for the classic layout or the Lightning Record Pages section for the Lightning experience. You will add the comment surface here.
- Add the Case Comments related list
On the page layout, drag the Case Comments related list onto the layout so agents can read existing comments in context. On a Lightning record page, this appears through the Related List component.
- Expose the New Comment action
Add the standard New Case Comment quick action (or a custom one) to the Salesforce Mobile and Lightning Experience Actions section, so the action shows in the highlights panel and the Case feed publisher.
- Set the default visibility and save
Decide whether new comments should default to private, and use the layout or a validation rule to enforce it. Save the layout, then open a test Case to confirm an agent can add and read a comment.
Shows existing comments on the Case so agents have the full history before they reply.
The button agents click to add a comment; can be the standard action or a custom action with a tailored layout.
Controls whether a new comment starts as customer-facing; default it to private to avoid accidental exposure.
The feed-based composer in the Service Console where the comment action can live alongside email and log-a-call.
- Published case comments can be sent to the contact in notification emails, so review the Case email templates before turning publishing on.
- A FeedComment cannot be edited once posted; agents must delete and re-post, which can break the flow of a thread.
- Deleting a Case deletes its CaseComments, so confirm your retention and archival policy before any bulk Case cleanup.
Prefer this walkthrough as its own page? How to Comment in Salesforce, step by step
Trust & references
Cross-checked against the following references.
Straight from the source - Salesforce's reference material on Comment.
Hands-on resources to go deeper on Comment.
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. Which fields define the standard CaseComment object in Salesforce?
Q2. Which Comment type is tied directly to a post in the Chatter Feed?
Q3. What does the IsPublished flag control on a Case Comment?
Discussion
Loading discussion…