Zendesk has no built-in way to run a ticket export on a recurring schedule. Here's the native route to build one yourself, and the shortcut if you'd rather not.
If you've gone looking for a setting that says "export this view every Monday morning," you won't find one. Zendesk offers no native scheduled ticket export, and the things that look like they might do the job each fall short in a specific way.
Exporting a view is a manual action. You click export, Zendesk builds a CSV, and it arrives as a link in an email you then have to open and download — every single time. There's no setting that repeats this for you; a human has to trigger it and fetch the result on each occasion.
Explore looks closer, since its scheduled dashboard delivery can send an Excel, CSV, PDF, or image export on a real schedule. The catch is that it only sends what's already built into that dashboard. If you need an arbitrary ticket-level field set — a combination of standard and custom fields you haven't already modelled as a dashboard — scheduled delivery doesn't let you define that ad hoc. You'd have to build the dashboard first, and even then you're exporting a report, not a live ticket-level table.
Admin → Reports has its own data export, and it's tempting because it's a genuine full-account dump. The problem is exactly that: it dumps the whole account, and because it records history rather than current state, a ticket that changes status three times over its life shows up as three separate rows. That's correct for an audit trail, but the wrong shape for a clean, current spreadsheet of "here's where every open ticket stands right now."
Finally, views themselves have a structural limit worth knowing before you build anything on top of them: there's no calendar-month condition. A view can filter on relative windows — "created in the last 30 days," hours-since-style conditions — but it can't cleanly express "give me June" as a fixed calendar range. If your reporting cadence is monthly and calendar-aligned, a view alone won't hold still long enough to be reusable without editing it every month.
None of the above rule out a scheduled export — they just mean Zendesk won't hand you one. If you're comfortable with the Zendesk API and Google Apps Script, here's the shape of a system that actually works.
If a Zendesk view already expresses the ticket set you want, pull it through /api/v2/views/{id}/tickets.json. It's cursor-paginated, 100 tickets per page, and it's the simplest route when a view's relative-window filtering is good enough for your use case.
If a view can't express what you need — most commonly because you need a genuine calendar-bounded query, or a filter combination views don't support — you need the search export endpoint instead, along with a plan for its own 1,000-result behaviour and cursor lifetime. That's a big enough topic on its own that it has its own guide; read that before you commit to building the search-export path. For a broader look at when a view, a search, or Explore is the right tool in the first place, see views vs. search vs. Explore.
Ticket payloads reference people by numeric ID, not name, which is useless in a spreadsheet a human is going to read. Batch those IDs through /api/v2/users/show_many.json in batches of 100, build an ID-to-name lookup, and join it onto your ticket rows before you write anything to the sheet.
The scheduling half of "scheduled export" is where a self-built version usually gets more complicated than people expect, because of three specific Apps Script constraints:
UrlFetchApp calls per day on a consumer Google account. That's generous for a handful of reports, but it's a real ceiling worth designing around deliberately — page size and polling frequency both eat into it — rather than discovering it mid-export.Because a single run might only get through part of a large export before the six-minute cap, write rows to the destination tab as you go rather than assembling the full result in memory. A resumed run then picks up cleanly, and a partial failure doesn't cost you data already fetched.
Put together, that's a dispatcher function, a cursor-persistence layer, ID-resolution logic, and incremental writes — a small piece of integration software you now own and maintain, even if the end result is "just" a spreadsheet tab that refreshes itself. It's entirely doable. It's just worth knowing the scheduling logic, not the API calls, is where the real effort goes.
Zendesk Exporter is a Google Sheets add-on that already implements the dispatcher, the cursor persistence, and the ID-resolution described above, so you configure a query instead of writing the scheduling logic yourself. You point it at a Zendesk view or a search — see the linked guide above if you're not sure which fits your case — choose the columns you want, and set a refresh cadence.
Worth being precise about what it does and doesn't cover, since it's not a full replacement for a hand-built integration in every case: it exports ticket fields, not the comment or description bodies of a ticket. Schedules run hourly, daily, or weekly — there's no monthly option, so a genuinely calendar-aligned monthly report still needs the same relative-window thinking discussed above. It connects to one Zendesk subdomain at a time, and it doesn't export users or organisations, only tickets. The free tier covers one saved query with manual refresh; Pro is A$15/month for unlimited saved queries plus hourly, daily, or weekly scheduled refresh.
If you'd rather configure a schedule than build one, install Zendesk Exporter and set up your first scheduled report in a few minutes.
Install from Google Workspace Marketplace See Zendesk ExporterLast reviewed 25 July 2026.