Proposal: Zammad ticket integration

Would a native Zammad integration be welcome in the open-source core? I have a working local prototype, but before turning it into a PR I would like to align on architecture and scope.

Proposed MVP:

An explicit action from an item creates a Zammad ticket in a configured, allowed group.
Durable mapping plus search-before-create reduces duplicate risk. Ambiguous POST outcomes remain search-only until an administrator explicitly allows another creation attempt.
Polling refreshes the ticket status shown on the item and can optionally trigger a transition through the existing workflow service.
API tokens are encrypted and connections can be restricted to selected workspaces.
No bidirectional field, comment, or attachment sync and no webhooks initially.

The prototype reuses the existing integration provider, external-link, credential, permission, and workflow infrastructure while adding provider-specific persistence and API/UI surfaces. Automated backend, frontend, and schema checks pass, but neither Zammad nor PostgreSQL has been exercised live yet.

Questions:

Is this integration desirable in the open-source core?
Would you prefer a dedicated provider or a more generic external ticket-system abstraction?
Is polling acceptable for the MVP, or should the design start with webhooks?
Would you prefer one full-stack PR or smaller backend and UI changes?
Which Zammad versions and live-test evidence would you expect before review or merge?

If the direction fits, I am happy to live-test it and open a draft PR.

@Optic00

Hey @Optic00 - yes that will totally work, I dont see a reason not to do it

A couple of questions on the design:

We might have some functional overlap between Zammad and Windshift, we need to signal where that integration makes sense
Bidirectional Comment sync will probably be requested very soon if this goes live, so we need to account for it - unless we design the integration to hand-off a ticket and only sync back the status to Zammad, what do you think?
Is a Zammad side functional change necessary, what happens if they dont accept it in the upstream? Any existing integrations that we coud use as a blue print, for example Jira?
Using the native oauth provider interface would be best. Functional extensions there are welcome to accommodate additional integrations, feel free to submit those
Polling is acceptable
Lets do a full PR, we can discuss everything in one piece
I can install Zammad and we can even possibly integrate it in the test suite to do a complete end-to-end test.

I am currently finishing up publishing the core-tests repo so bigger PRs can be properly tested

Thanks. #238 follows the functional boundaries, with one open OAuth question.

Responsibility split: Windshift owns planning and the internal work item. Zammad owns intake, communication, routing, SLAs, and resolution. Windshift observes state, group, and owner and permits explicit updates, but does not mirror the ticket.
Comments: The item description becomes the initial internal Zammad note. There is no later comment or attachment sync. Bidirectional sync needs a separate design for article visibility, identities, permissions, edits, attachments, and loop prevention. I would start with an explicit "send update to Zammad" action.
Zammad dependency: No Zammad source change or plugin is required. The standard REST API, a restricted service account, and an administrator-created text attribute provide correlation and duplicate protection. The field can use Zammad's standard link template for the return link. The Jira integration is import-oriented and not a direct blueprint.
OAuth: feat: add Zammad ticket integration #238 implements Zammad's authorization-code flow, but does not extend Windshift's IntegrationOAuthHandler, currently limited to per-user Notion/Todoist connections. Zammad uses administrator-owned provider records and encrypted credentials. If the common interface should cover system-owned connections, I can refactor this before merge.
Polling/testing: Polling runs two minutes after each completed run, with manual refresh for one or all tickets. It has been tested in a private lab against Zammad 7.1.1 with PostgreSQL, but not in production. I am happy to add a Zammad-backed core-tests scenario.

Does that split and the proposed OAuth boundary match what you had in mind?

Update on the open OAuth question: I went ahead with the refactor. IntegrationOAuthHandler now covers system-owned connections alongside the existing per-user ones, and Zammad registers through that interface instead of carrying its own flow. That matches your point about extending the native provider interface rather than working around it.

#238 is rebased onto current main after the v2 route migration, and all checks are green.

Still open from your list is the end-to-end evidence. The lab side is Zammad 7.1.1 with PostgreSQL; I will add a Zammad scenario to core-tests once that repo is public.

Closing this as its merged, thanks again for the contribution! Will spin up Zammad this week to test it and to produce some documentation as well

Navigation Menu

Repository navigation

Proposal: Zammad ticket integration #234

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Proposal: Zammad ticket integration #234

Description

Activity

stefan-ernst commented on Aug 30, 2026

Optic00 commented on Aug 31, 2026

Optic00 commented on Sep 4, 2026

stefan-ernst commented on Sep 14, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions