Zammad n8n integrationAutomate Zammad with n8n.

Groups are the queues a ticket lands in, and this operation adds one from a workflow rather than from the admin screen. Handy when a new team or a new product line needs its own inbox.

• Group Name: the only required field, the label agents see in the queue picker, often fed by an expression such as {{ $json.team }}.
• Additional Fields: three optional entries, Active to open or freeze the queue right away, Notes for an internal description, Custom Fields for anything your instance added.

Removes a queue from the instance. This one belongs at the end of a cleanup workflow, not in a run that fires every hour, since there is no undo step in the node to pair it with.

• Group ID: the identifier of the group, not its name. An expression is the usual way to fill it, for example {{ $json.id }} carried from a Get many groups step.

Reads a single group and returns its record. A workflow uses it to confirm a queue exists, and to look at its notes, before routing anything into it.

• Group ID: the group to retrieve. The field accepts an expression, so a value carried from an earlier node drops straight in.

Returns the groups configured on the instance. It is the simplest way to turn queue names into the identifiers every other Group operation expects.

• Return All: on, n8n keeps asking the Zammad API for the next page until every group is in. Off, the run stops at Limit.
• Limit: the maximum number of groups returned when Return All stays off, useful while you shape a workflow.

Edits a queue in place. Renaming a team or freezing a queue during a migration goes through here, rather than deleting and recreating the group and losing its identifier.

• Group ID: identifies the queue to edit, required even when a single field changes.
• Update Fields: four optional entries, Group Name for the new label, Active to freeze or reopen, Notes, Custom Fields.

Companies live in Zammad as organizations. This operation creates one from whatever a CRM or a signup form sends, so later tickets attach to an account instead of to a lone email address.

• Organization Name: required, the company label shown on every linked ticket.
• Additional Fields: seven optional entries. Domain with Domain Assignment attaches users by their email domain, VIP flags a key account, then Shared, Active, Notes and Custom Fields.

Takes a company record out of the instance. Put it behind an approval step in a data hygiene workflow, because other records point at an organization and nothing in the node puts it back.

• Organization ID: the record to remove, set through an expression when the value comes from a previous node.

Fetches one organization and returns its fields, including the notes and the VIP flag that an agent would otherwise open a browser tab to read.

• Organization ID: the record to retrieve. A company name will not work here, the field expects the identifier.

Reads the organization list. This is the export operation of the resource, the one that feeds reporting living outside the help desk.

• Return All: enabled, every organization comes back page after page, which is what a complete export needs.
• Limit: with Return All off, this caps how many organizations a single execution returns.

Applies changes to a company that already exists. Nothing is required beyond the identifier, so a workflow can touch one field and leave the rest of the record untouched.

• Organization ID: which record to edit.
• Update Fields: seven optional entries, the same set as creation. VIP and Active change how the account is treated, Domain and Domain Assignment change who gets attached to it.

Most Zammad workflows end on this operation. It opens a ticket in a chosen queue, for a known customer, with a first message attached.

• Title: required, what agents scan in the queue.
• Group Name or ID: required, the queue that owns the ticket. Pick it from the list, First-Level Helpdesk for instance, or pass an ID by expression.
• Customer Email Name or ID: required, the email address of the customer concerned, such as {{ $json.email }}.
• Article: required, the first message, with Body, Article Type (chat, email, fax, note, phone or sms) and Visibility, where internal stays with the help desk.

Deletes a ticket by identifier. Rarely part of a routine flow, more often a cleanup step for test tickets or for items a loop created twice.

• Ticket ID: the ticket to delete, given as an identifier through an expression when it comes from an earlier step.

Retrieves one ticket with its current fields. That is how a workflow reads state, owner and priority before deciding what to do next.

• Ticket ID: the ticket to retrieve, passed as an identifier, usually {{ $json.id }} from the item that opened the branch.

Lists tickets from the instance. Paired with a Schedule Trigger, it is as close as this node gets to a trigger, since Zammad has no trigger node in n8n.

• Return All: on, n8n keeps requesting pages until the whole list is retrieved, which reporting runs need.
• Limit: with Return All off, this sets the maximum number of tickets returned, enough for a daily digest.

Day-to-day automation mostly sits here. One call can reassign, reprioritize, change the state and drop an internal note on the same ticket.

• Ticket ID: the only required value.
• Update Fields: nine optional entries. State, Priority, Owner, Group and Customer come from lists or expressions, Note adds an internal comment, Title rewrites the subject.
• Pending Time: the date and time a pending ticket becomes active again, required for the pending reminder, pending close and snooze states.

Adds a person to Zammad. Two names are enough to get a record in, everything else rides along in the optional collection.

• First Name and Last Name: the two required fields, John and Smith in the node placeholders.
• Additional Fields: 13 optional entries. Email Address matters most, since ticket creation identifies a customer by email, then Organization Name or ID, Phone (Mobile), Department, VIP and Verified.

Erases a user record. The identifier is the only input, which makes this operation easy to wire and easy to fire by mistake. Put a filter in front of it.

• User ID: the record to remove, specified through an expression when the value arrives from a previous node.

Single-record lookup. Returns the person behind an identifier, with the organization, the contact details and the flags that were filled in.

• User ID: the identifier of the user to read, not the email address.

Searches the user base and returns a list. This operation carries a Filters collection the other list operations do not have, which makes it a search rather than a dump.

• Query: a search string such as user.firstname:john, which narrows the result set before it reaches n8n.
• Sort: orders the results on the way out.
• Return All and Limit: every match, or a capped number while you refine the query.

Returns the account the credential authenticates as, with its identifier and its details as Zammad stores them. There is nothing to configure: no record ID, no expression, no optional collection. That makes it the fastest way to prove a credential actually works before building anything on top of it.

Keeps a contact record current. The identifier decides who changes, the optional collection decides what, and untouched fields stay as they were.

• User ID: required, the record to edit.
• Update Fields: 15 optional entries, the widest collection in the node. Organization Name or ID moves someone to another company, Email Address, Phone (Landline) and Website refresh contact details, Active retires an account without deleting it.