feat(conversations): import zendesk ticket tags

[abigailbramble]

Problem

Zendesk tickets carry tags, and teams rely on them to categorize and filter their support queue. The historical Zendesk import fetches the full ticket payload (which includes the tags array) but silently discards it, so imported tickets arrive untagged and teams lose that categorization.

Changes

Newly imported tickets now get their Zendesk tags, wired into PostHog's product-wide tag system (Tag/TaggedItem) rather than stored as loose strings:

• Each ticket's tags array from the Zendesk payload is normalized the same way the live tagging API does (tagify: lowercase + strip, empties dropped, deduped per ticket). No extra Zendesk API calls - the tags are already in the show_many response the import fetches.
• Tag names resolve to team-scoped Tag rows via get_or_create, matching the live apply path (set_tags_on_object): existing tags are reused, new ones created, never duplicated per team.
• TaggedItem links are bulk-created inside the import transaction after tickets get their IDs.

Because tags land in the shared tag system, imported tickets immediately work with everything tags already support: the ticket list's tags/tags_all/tags_exclude filters, tag display, and cross-product tag queries.

Note

The TaggedItem links use bulk_create, which skips save()/full_clean() and signals on purpose - the same no-signals rule as every other historical write in this import. Tags are applied only to tickets the import creates; already-imported (skipped) tickets are deliberately untouched.

How did you test this code?

• Added one test covering the matrix: normalization ("Billing", " URGENT " → billing, urgent), empty tags dropped, a pre-existing team tag reused instead of duplicated, one Tag row shared across tickets in a batch, and untagged tickets staying untagged. No existing test exercised tags in the import, so this catches regressions in the mapping, normalization, or per-team dedupe.
• Ran the full zendesk_import/tests/test_activities.py suite locally: 25 passed.
• Manually verified on a local stack: ran an import against Zendesk and the newly imported tickets came in with their tags applied.

Automatic notifications

• Publish to changelog?
• Alert Sales and Marketing teams?

Docs update

🤖 Agent context

Autonomy: Human-driven (agent-assisted)

• Authored with PostHog Code (Claude). Skills invoked: /writing-tests.
• Scoping decision (confirmed with the driver): tags apply to newly imported tickets only. Backfilling tags onto already-imported tickets on re-import was considered and rejected - skipped tickets are never re-fetched from Zendesk today, so backfill would add a fetch to the skip path for a one-time repair.
• Tag rows are resolved with get_or_create before the ticket transaction to keep the lock window narrow; a Tag row left behind by a failed batch is harmless and reused on retry.

---

Created with PostHog Code

[greptile-apps]

_{Reviews (1): Last reviewed commit: "feat(conversations): import zendesk tick..." | Re-trigger Greptile}

[hex-security-app]

The open thread about long tag-name collisions does not describe a security vulnerability in this code path. Truncating normalized Zendesk tags to fit the Tag.name column can merge distinct labels and affect categorization/filtering, but it does not create a plausible confidentiality, integrity, auth, or availability exploit beyond ordinary data correctness. I’m not filing a security finding for it.

[trunk-io]

     

View Full Report ↗︎ ⋅ Docs

[veryayskiy]

🚢

[deployment-status-posthog]

Deploy status

Environment	Status	Deployed At	Workflow
dev	✅ Deployed	2026-07-13 11:21 UTC	Run
prod-us	✅ Deployed	2026-07-13 11:34 UTC	Run
prod-eu	✅ Deployed	2026-07-13 11:36 UTC	Run