Zendesk CSV Import

The Zendesk CSV import is genuinely good at users and organizations. For tickets it's a blunt instrument, and knowing that early saves a weekend.

What the Zendesk CSV import is built for

Bulk creation of users and organizations through a CSV upload in the admin interface. That's the job it does well, and for a new Zendesk account it is the fastest way to get your customer list in.

It handles the fields you would expect: name, email, role, organization, tags, plus custom user and organization fields you've already created. Note the ordering there. The field must exist in Zendesk before the column can map to it, so build your fields first.

Ticket import through the interface exists in a much more limited form, and Zendesk's guidance on it has shifted over the years. Check the current documentation for what your account offers before you plan a migration around it, because the answer today may not match a forum post from three years ago.

Preparing a file that imports first time

Most failed imports fail for boring reasons. Work through these before you upload anything.

UTF-8, comma separated, one header row. Exports from older spreadsheet tools love to produce something else.
Header names matching what the importer expects. Get this from the current docs, not from memory.
Email as the identity key. Duplicate email addresses in your file will not create two users, they will collide, and the outcome may not be the one you wanted.
Organizations before users. A user row referencing an organization that does not exist yet either fails or creates something unexpected.
Test with twenty rows. Always. Import twenty, look at what actually landed, then run the rest. Nobody has ever regretted this and plenty of people have regretted skipping it.

A minimal users file looks roughly like this:

name,email,role,organization,tags
Jane Okafor,jane@acme.com,end-user,Acme Corp,vip
Sam Reyes,sam@acme.com,end-user,Acme Corp,

What it won't do

This is the part worth reading twice, particularly if you are migrating from another helpdesk.

Attachments. Not through CSV. If historic screenshots matter, CSV is not your route.
Full conversation threads with correct authorship. A ticket is a sequence of comments by different people at different times. A flat row doesn't express that.
Original timestamps and history. Imported records generally take on their creation date in Zendesk, which destroys any historic reporting you were hoping to preserve.
Original ticket IDs. Your old reference numbers will not be the new ones. If customers quote old IDs, put the legacy ID in a custom field.
Satisfaction ratings, SLA history, audit trails. None of it comes across.

The honest summary: CSV gives you records, not history. That is a perfectly reasonable trade if what you need is a current customer list. It's a disaster if somebody was promised the last three years of tickets.

When you need the API instead

Reach for the API the moment any of these are true.

You need real conversation history, with correct authors and timestamps on each comment.
You need attachments.
The volume is large. Interface imports have practical size limits, and splitting a migration into forty files by hand is its own kind of misery.
It has to run more than once, as an ongoing sync from a CRM or a billing system.
You need to verify what landed. An API import gives you a response per record. A CSV upload gives you a summary and a shrug.

Zendesk provides a dedicated ticket import path in the API designed for exactly this, letting you set created dates and comment authors in a way normal ticket creation does not. It is more work up front and it is the only route that produces a migration you can defend afterwards. Start with the API guide, and if you're moving between helpdesks read the migration guide first.

A sane import order

Sequence matters more than tooling. Do it in this order and most of the pain disappears.

Custom fields first, then organizations, then users, then tickets. Every stage depends on the one before it, and reversing any two of them produces orphaned records you'll spend a day cleaning up.

Before you start, decide what you are deliberately not bringing. Closed tickets older than a year are usually the answer. Keeping an export of the old system as an archive is cheaper, faster and safer than importing history nobody will read. If you need that archive from Zendesk later, exporting tickets covers the routes.

One thing to check after any bulk user import: whether the same person now exists twice under two addresses, because that quietly turns future tickets from one human into two unrelated records.

FAQ

Frequently asked questions

Can you import organizations from CSV?

Yes, and do it first. Zendesk import organizations from their own file, then import users referencing them by name, or the user rows land without an organization attached.

Can I import users and organizations from CSV too?

Yes, and it's the part the importer is genuinely good at. A Zendesk import users CSV run matches on email, and to import organizations you upload a separate file first so the user rows can reference them. For anything past a few thousand rows, treat Zendesk bulk import as an API job.

Can I import tickets into Zendesk from a CSV?

In a limited form, and without attachments, full comment threads or original timestamps. For a real migration with history, the API ticket import path is the route that works.

What can the Zendesk CSV importer handle well?

Users and organizations, including custom fields you have already created. For a new account it's the quickest way to load your customer list.

Will a CSV import preserve my original ticket dates?

Generally no. Imported records take on their Zendesk creation date, which is why historic reporting after a CSV migration rarely survives. The API import can set created dates.

What order should I import things in?

Custom fields, then organizations, then users, then tickets. Each stage references the previous one, and doing it out of order creates orphaned records.

Is there a size limit on Zendesk CSV imports?

There are practical file size and row limits on interface uploads, and they change. Check the current Zendesk documentation, and use the API for anything large or repeated.

Imports are a common duplicate source

Bulk loads create the same person twice under two addresses. Ticket Merger catches the tickets that follow.

Start free trial

14-day free trial. No credit card required.