Existing Ticket Handling Documentation

Handle Existing Zendesk Tickets in Notion

Choose whether duplicate ticket exports should be skipped, duplicated, or replaced, and use the right mode for your workflow.

Handle Existing Zendesk Tickets in Notion

In this doc

existing Zendesk ticket handling skip duplicate replace Zendesk to Notion duplicate export behavior

Zendesk to Notion does not blindly create a new Notion page every time.

Before export, it checks whether the same ticket already exists in the selected Notion database by Ticket ID. What happens next depends on your Existing Ticket Handling setting.

Where to find this setting

You can configure duplicate behavior during setup in both the popup and the bulk export page.

The setting is stored locally in the extension, so you do not need to reselect it on every export.

Option 1: Skip

Skip means:

  • if the ticket already exists in Notion, do not create a new page
  • return the existing Notion page instead
  • mark the export as skipped

Use Skip when you want one canonical page per ticket and do not want repeated exports to create noise.

This is usually the best choice for:

  • product feedback databases
  • shared triage boards
  • any workflow where Ticket ID should be unique

Option 2: Add New

Add New means:

  • keep the existing page
  • create another Notion page for the same ticket

Use Add New only if duplicates are intentional.

This can make sense when:

  • different teams want separate snapshots of the same ticket
  • you are using Notion as a working log, not a deduplicated ticket database

If you do not have a clear reason to keep multiple copies of the same ticket, this is usually the least safe option.

Option 3: Replace

Replace means:

  • find existing pages with the same Ticket ID
  • archive those pages first
  • create a fresh page with the current ticket data

Use Replace when you want a clean current-state export without accumulating old copies.

This is often the best option for:

  • ongoing bug review databases
  • support-to-product workflows where the newest export should win
  • teams that regularly re-export the same ticket after status or notes change

How the export result looks

The extension makes the outcome explicit:

  • skipped tickets are shown as skipped
  • replaced tickets are labeled as replaced
  • newly created tickets are treated as successful exports

This matters most in batch export, where teams need to know whether a run created new pages or simply recognized existing records.

Which option should most teams choose?

A simple rule works well:

  • choose Skip if your database is meant to be unique by ticket
  • choose Replace if your database should always reflect the latest export
  • choose Add New only if duplicates are part of the design

If you are unsure, start with Skip. It is the safest default.

Duplicate handling only works reliably if:

  • your Notion database includes Ticket ID
  • the property type is compatible with the exporter’s expectations

Without that field, duplicate detection becomes unreliable or impossible.