Integración Zammad n8nAutomatiza Zammad con n8n.

Los grupos son las colas donde aterrizan los tickets. Esta operación crea una desde un flujo, sin pasar por la pantalla de administración. Sirve cuando un equipo nuevo o una línea de producto necesita su propia bandeja.

• Group Name: el único campo obligatorio, la etiqueta que los agentes verán en el selector de cola, alimentada a menudo por una expresión como {{ $json.team }}.
• Additional Fields: tres entradas opcionales, Active para abrir o congelar la cola al momento, Notes para la descripción interna y Custom Fields para lo que tu instancia haya añadido.

Retira una cola de la instancia. Va al final de un flujo de limpieza, no en una ejecución que corre cada hora: el nodo no ofrece ninguna operación inversa con la que recuperar lo borrado.

• Group ID: el identificador del grupo, no su nombre. Se rellena por expresión, normalmente {{ $json.id }} recogido de un paso Get many groups.

Lee un grupo y devuelve su ficha. Un flujo lo usa para confirmar que una cola existe, y para releer sus notas, antes de enrutar nada hacia ella.

• Group ID: el grupo a recuperar. El campo acepta una expresión, es decir una referencia al dato que trae el nodo anterior.

Devuelve los grupos configurados en la instancia. Es el camino más corto para convertir nombres de cola en los identificadores que piden todas las demás operaciones de Group.

• Return All: marcado, n8n pide a la API de Zammad página tras página hasta traer todos los grupos. Sin marcar, la ejecución se detiene en Limit.
• Limit: el número máximo de grupos devueltos cuando Return All queda desactivado, cómodo mientras afinas un flujo.

Modifica una cola sin moverla. Renombrar un equipo o congelar una cola durante una migración pasa por aquí, y no por un borrado seguido de un alta que haría perder el identificador.

• Group ID: señala la cola a modificar, obligatorio aunque cambie un solo campo.
• Update Fields: cuatro entradas opcionales, Group Name para la nueva etiqueta, Active para congelar o reabrir, Notes y Custom Fields.

Las empresas viven en Zammad como organizaciones. Esta operación crea una con lo que manda un CRM o un formulario, para que los tickets siguientes se aten a una cuenta y no a una dirección huérfana.

• Organization Name: obligatorio, el nombre de empresa que aparece en cada ticket vinculado.
• Additional Fields: siete entradas opcionales. Domain junto a Domain Assignment engancha usuarios según su dominio de correo, VIP marca una cuenta clave, y luego Shared, Active, Notes y Custom Fields.

Saca una ficha de empresa de la instancia. Colócala detrás de un paso de aprobación dentro de un flujo de higiene de datos, porque otros registros apuntan a una organización y nada en el nodo la devuelve a su sitio.

• Organization ID: la ficha a eliminar, indicada por expresión cuando el valor llega de un nodo anterior.

Recupera una organización y devuelve sus campos, notas e indicador VIP incluidos, los que un agente iría a leer en otra pestaña del navegador.

• Organization ID: la ficha a leer. Un nombre de empresa no funciona aquí, el campo espera el identificador.

Lee la lista de organizaciones. Es la operación de exportación del recurso, la que alimenta los cuadros de seguimiento que viven fuera del soporte.

• Return All: activado, todas las organizaciones vuelven página tras página, que es lo que exige una exportación completa.
• Limit: con Return All desactivado, este campo pone techo a cuántas organizaciones devuelve una ejecución.

Aplica cambios a una empresa que ya existe. Nada es obligatorio más allá del identificador, así que un flujo puede tocar un solo campo y dejar el resto de la ficha intacto.

• Organization ID: la ficha a modificar.
• Update Fields: siete entradas opcionales, el mismo juego que en el alta. VIP y Active cambian el trato que recibe la cuenta, Domain y Domain Assignment cambian quién se engancha a ella.

La mayoría de los flujos de Zammad terminan en esta operación. Abre un ticket en la cola elegida, para un cliente conocido, con un primer mensaje.

• Title: obligatorio, lo que los agentes leen al repasar la cola.
• Group Name or ID: obligatorio, la cola dueña del ticket. Se elige de la lista, First-Level Helpdesk por ejemplo, o se pasa por expresión.
• Customer Email Name or ID: obligatorio, el correo del cliente implicado, del tipo {{ $json.email }}.
• Article: obligatorio, el primer mensaje, con Body, Article Type (chat, email, fax, note, phone o sms) y Visibility, donde internal queda solo para el soporte.

Elimina un ticket a partir de su identificador. Rara vez en un flujo de rutina, más bien como paso de limpieza para tickets de prueba o para duplicados que dejó un bucle ejecutado dos veces.

• Ticket ID: el ticket a borrar, dado como identificador mediante una expresión cuando viene de un paso anterior.

Recupera un ticket con sus campos tal y como están ahora. Así es como un flujo lee el estado, el propietario y la prioridad antes de decidir qué hacer.

• Ticket ID: el ticket a leer, pasado como identificador, casi siempre {{ $json.id }} desde el elemento que abrió la rama.

Lista los tickets de la instancia. Junto a un Schedule Trigger es lo más parecido a un disparador que hay aquí, ya que Zammad no tiene nodo trigger en n8n.

• Return All: marcado, n8n encadena páginas hasta recuperar la lista entera, que es lo que necesita un informe.
• Limit: con Return All sin marcar, fija el número máximo de tickets devueltos, suficiente para un resumen diario.

Aquí se juega casi toda la automatización del día a día. Una sola llamada reasigna, cambia la prioridad, cambia el estado y deja una nota interna en el mismo ticket.

• Ticket ID: el único valor obligatorio.
• Update Fields: nueve entradas opcionales. State, Priority, Owner, Group y Customer salen de listas o de expresiones, Note añade un comentario interno, Title reescribe el asunto.
• Pending Time: fecha y hora en que se reactiva un ticket en espera, obligatoria para los estados pending reminder, pending close y snooze.

Añade una persona a Zammad. Con dos nombres ya hay ficha, todo lo demás viaja en la colección opcional.

• First Name y Last Name: los dos campos obligatorios, John y Smith en los ejemplos del nodo.
• Additional Fields: 13 entradas opcionales. Email Address es la que más pesa, porque la creación de tickets identifica al cliente por su correo, y luego Organization Name or ID, Phone (Mobile), Department, VIP y Verified.

Borra una ficha de usuario. El identificador es la única entrada, lo que hace la operación fácil de cablear y también fácil de disparar por error. Pon un filtro delante.

• User ID: la ficha a retirar, indicada por expresión cuando el valor llega de un nodo anterior.

Lectura de una sola ficha. Devuelve a la persona que hay detrás de un identificador, con su organización, sus datos de contacto y los indicadores rellenados.

• User ID: el identificador del usuario a leer, no su correo.

Busca en la base de usuarios y devuelve una lista. Esta operación lleva una colección Filters que las otras listas no tienen, y eso la convierte en una búsqueda de verdad y no en un volcado.

• Query: una cadena de búsqueda como user.firstname:john, que acota el resultado antes de que llegue a n8n.
• Sort: ordena los resultados a la salida.
• Return All y Limit: todos los resultados, o un número con techo mientras afinas la consulta.

Devuelve la cuenta con la que se autentica el credential, con su identificador y sus datos tal y como los guarda Zammad. No hay nada que configurar: ni identificador de ficha, ni expresión, ni colección opcional. Por eso es la forma más rápida de demostrar que un credential funciona antes de construir nada encima.

Mantiene al día una ficha de contacto. El identificador decide a quién, la colección opcional decide qué, y los campos que no tocas se quedan como estaban.

• User ID: obligatorio, la ficha a modificar.
• Update Fields: 15 entradas opcionales, la colección más amplia del nodo. Organization Name or ID mueve a alguien a otra empresa, Email Address, Phone (Landline) y Website refrescan los datos de contacto, Active retira una cuenta de circulación sin borrarla.