Zendesk Ticket History in Salesforce: What Carries Over and What Doesn't

Most Zendesk migration plans focus on moving the records. The complaints after go-live are about Zendesk ticket history in Salesforce: the details around those records. "Where is my ticket #48213?" "Why does every comment say it was written today?" "Why can customers see internal notes?"

This post covers five of those details, and says plainly which behavior is documented by Salesforce or Zendesk and which you need to test in your own sandbox. It's a companion to our full Zendesk to Salesforce data migration guide, which covers the whole process.

1. Ticket numbers: Salesforce picks the Case Number, not you

The Case Number field is assigned automatically when a case is inserted. Salesforce's Case object reference says it can't be set directly and can't be modified after the case is created. So a Zendesk ticket ID can never become the Case Number.

The workable approach is to keep the Zendesk ID next to it:

• Create a unique External ID field on Case (for example, Zendesk Ticket ID) and load it with every case.
• Put that field on the page layout so agents can see it.
• Use the same field to link comments and attachments back to the right case during the load.

Then list everything outside Salesforce that quotes old ticket numbers: customer emails, Jira links, reports, macros, internal docs. Decide which of those get updated and which get a lookup instead.

2. Dates: original timestamps only survive if you set them at insert

Salesforce's help article on importing audit fields says CreatedDate, CreatedById, LastModifiedDate and LastModifiedById can be set only when a record is created, not afterward, and only with the right feature and user permission enabled.

CaseComment needs extra care. The CaseComment object reference tells you to contact Salesforce if you're importing CaseComment data and must set an audit field such as CreatedDate. Don't assume your comments will keep their original dates. Find out before the first load.

3. Authors: customers aren't Salesforce users

Zendesk's Ticket Comments API gives every comment an author_id. In Salesforce, the author of a record is the user in CreatedById. That works for agents who become Salesforce users. It doesn't map cleanly for two groups:

• Customers. They're Contacts, not users (unless they're Experience Cloud users). Put their name in a custom field or at the top of the comment body.
• Agents who left. Decide up front whether they get a user record, or whether their comments are attributed to a placeholder user with the real name in the body.

No documentation makes this decision for you. It's a design choice, so make it before you build the load.

4. Public and private comments: map the flag explicitly

Zendesk comments are either public or private. In Salesforce, the matching field on CaseComment is IsPublished, which controls whether the comment is visible to customers in the Self-Service portal. Its default value is false.

If you leave IsPublished out of the load, every migrated comment arrives unpublished. The good news: IsPublished is the only CaseComment field you can update after insertion, so a mistake here can be fixed without reloading.

If you store comments as feed items instead, set Visibility explicitly. The Chatter REST API documents two values: AllUsers and InternalUsers. For help choosing between the two storage options, read our article on Chatter feed or Case Comment.

5. Length limits: check your longest comments first

CaseComment.CommentBody has a maximum size of 4,000 bytes. Note the unit is bytes, so text with accented or non-Latin characters reaches the limit sooner than plain English. Feed item and comment bodies in Chatter have a 10,000 character limit, and Salesforce recommends confirming the current limit with a describe call because it can change.

On the Zendesk side, one ticket can hold up to 5,000 comments. Long email threads pasted into single comments are the usual problem. We've hit length problems on Case Description, Case Comment and Chatter posts in real projects, so measure your longest comments before you pick a target.

One more rule worth knowing: through the API, CaseComment records can't be modified after insertion unless the user has Modify All Records on Cases or Modify All Data. Get the text right on the first sandbox run, not the third.

Quick reference

Documented vs. test it yourself

Before your first sandbox load

1. Create the Zendesk Ticket ID External ID field on Case.
2. Confirm whether audit fields can be set on Case and CaseComment.
3. Decide how customer and former-agent authors will be shown.
4. Map the public/private flag to IsPublished.
5. Run a length check on your longest comments.
6. List every outside system that quotes old ticket numbers.

References

• Salesforce Object Reference: Case (CaseNumber)
• Salesforce Object Reference: CaseComment (CommentBody, IsPublished, audit fields, modify rules)
• Salesforce Help: Set 'Audit' Field Values for Imported Records
• Chatter REST API: Feed Elements (10,000 character limit, visibility)
• Zendesk API: Ticket Comments (public/private, author_id, 5,000 comment limit)

Salesforce limits and behavior change between releases. Check the current documentation for your API version before you finalize your plan.