Exporting Salesforce case history with feeds, emails and comments

Which objects hold a case's full history?#

A Salesforce case's full history is spread across several standard objects, and the Case record itself holds only the header: subject, status, priority, owner, account, contact and timestamps. The back-and-forth with the customer and the internal discussion live in child objects, each exported as its own file.

Calls and tasks logged against the case sit in the Task object, linked through WhatId, and chat or messaging transcripts live in their own objects. Include them if your team handled cases by phone or chat as well as email.

How the keys rejoin one case thread#

The case ID rejoins a Salesforce case thread: CaseComment, EmailMessage and FeedItem carry it in ParentId, CaseHistory carries it in CaseId, and file links carry it in LinkedEntityId. Feed comments join one step further out, through their feed item, and files attached to emails link to the EmailMessage rather than the case.

Keep timestamps in UTC as Salesforce returns them and convert only for display. Mixed time zones are a common reason a rebuilt thread shows the answer before the question.

• 1Step 1: export Case with Id, CaseNumber, AccountId, ContactId, status fields, CreatedDate and ClosedDate.
• 2Step 2: export each child object filtered to the cases in scope, keeping its ID, parent key, author and timestamp fields.
• 3Step 3: tag every row with its source and direction: inbound email, outbound email, public comment, internal note, feed post or field change.
• 4Step 4: sort each case's rows by time, using MessageDate for emails and CreatedDate elsewhere.
• 5Step 5: drop feed entries whose content duplicates an email or comment already in the thread; check the FeedItem Type values in your org to find them.
• 6Step 6: replace user, contact and account IDs with roles such as agent, engineer or customer before anyone outside support reviews the output.

Which export method fits your org?#

The right Salesforce export method for case history depends on volume, how often you need a copy and whether deleted or archived records must be included. Reports are the wrong tool here, because they are built for summaries, not full text bodies and every related record.

Whatever the method, write down the exact queries, the date of the pull and the user who ran it. A future reviewer needs to know whether the export covered every case or only open ones, and whether it included records sitting in the recycle bin.

What gets lost in a careless export#

A careless Salesforce case export usually loses email bodies, internal-note labels, older field history, deleted records and files, because it assumes the Case object holds more than it does. These gaps show up again and again when support teams first try to rebuild threads outside Salesforce.

• 1Email bodies left out because only EmailMessage header fields were selected.
• 2Internal notes mixed with customer-visible comments because IsPublished was not exported.
• 3Field history older than your org's retention, unless Field Audit Trail or an earlier backup kept it.
• 4Archived activities and deleted records, which ordinary queries skip.
• 5Inline images and attachments referenced in email or feed bodies but never downloaded.
• 6Email attachments in older orgs stored as classic Attachment records whose ParentId points at the EmailMessage, not the case.
• 7Chat and messaging transcripts stored in objects such as LiveChatTranscript or MessagingSession.
• 8User, Contact and Account tables, without which IDs cannot be turned into roles.

Illustrative: a scheduling software company rebuilds its support history#

Illustrative: a fictional maker of crew scheduling software for commercial cleaning companies has run support in Service Cloud for many years, with Email-to-Case, Case Feed and a customer portal. The CTO wants a full export before a planned move to another help desk and before any review of whether the history could be licensed.

The first pass uses the scheduled Data Export files and looks complete, but rebuilt threads show many emails twice: once as an EmailMessage and once as a Case Feed entry. The team filters feed items that mirror emails, labels internal notes using IsPublished, and pulls deleted and archived records with Data Loader.

Reconciliation then shows that field history reaches back only part of the way, so the team records that limit instead of implying a full audit trail. The final package links each case to the customer's product tier and to the Jira issue keys that engineers mentioned in internal notes.

How to prove the export is complete#

A Salesforce case export is proven complete with counts, samples and a written record of how it was produced. Run each check per object, not only for the Case file, and keep the results with the export itself.

Preparing case history for review or licensing#

Case history prepared for review needs three things beyond a complete export: clear labels for who wrote each entry, a record of what was removed, and a decision on which customers' cases are in scope. Threads that connect a customer's problem to the diagnosis and the fix are the kind of customer support record AI developers look for, which is why the labeling work in the rebuild steps pays off later.

Customer contracts and privacy obligations decide what can be used, and names, email addresses, phone numbers and signatures are removed during preparation. That redaction belongs to the Preparation step of the SourceX five-step transaction, which runs Supply, Rights, Preparation, Approval, Delivery in that order. Its fit check needs only metadata, such as case volumes by year and which objects are populated, and a SourceX Evidence Packet records the privacy work and permitted use for any package that proceeds.