Skip to content
English
Do you need help? Customer portal
neowit.io
  • There are no suggestions because the search field is empty.

Tickets

How workflows react to and act on tickets in your organization. For workflow authors wiring tickets into Slack, email, or other downstream actions.

Before you start

  • Tickets enabled for your org. Tickets are off by default; an admin turns them on at Settings → Tickets. See Enable tickets.
  • What a ticket is. This article covers only the workflow-facing surface. For the lifecycle (Open / In Progress / Resolved), the detail page, retention, and the rest of the operator experience, see the Tickets KB.

Five triggers fire on every state change

Every ticket transition emits a workflow trigger. Subscribe to the ones that match how your team wants to be notified:

  • Ticket Opened — fires when a ticket is created, regardless of source (health monitor, workflow, user report). The most common entry point for "alert on …" workflows.
  • Ticket Started — fires when an operator clicks Start (Open → In Progress).
  • Ticket Comment Added — fires on every comment posted to a ticket, including comments attached to a state change.
  • Ticket Resolved — fires when a ticket transitions to Resolved, whether by an operator clicking Resolve or by the health monitor auto-resolving after subject recovery.
  • Ticket Reopened — fires in two cases with the same payload: (a) the health monitor reopens a recently-resolved ticket because the subject failed again inside the reopen window, or (b) someone clicks Reopen on the detail page. Workflows subscribed to this trigger don't need to distinguish the two — the payload is identical.

Trigger payload reference: Triggers.

Three actions mutate tickets

  • Open Ticket — files a new ticket from an external signal (a scheduled check, an integration event, a button press). The ticket carries source: "workflow" and the actor on the open event is workflow:<service-account-id>, so it's distinguishable from health-monitor- and user-reported tickets when filtering or routing.
  • Resolve Ticket — marks an existing ticket Resolved. Useful for auto-clearing tickets when an external check passes.
  • Add Comment — appends a comment to a ticket. Use for narration ("automated retry succeeded at …") without changing state.

Action config reference: Actions. Canonical example: Alert when a device goes offline.

Telling workflow-opened tickets apart

A ticket filed by an Open Ticket action carries:

  • ticket.source == "workflow" — use this in an If condition if you want to route workflow-opened tickets differently from health-monitor ones.
  • The actor on the open event is workflow:<service-account-id> — visible on the activity timeline.

Anything filed by a workflow is otherwise indistinguishable from a health-monitor or user-reported ticket: it shows in the same Tickets list, accepts the same comments and state transitions, and emits the same downstream triggers.

Why your workflow might fire twice

Trigger delivery is at-least-once. If the service hits a transient delivery fault, the rendered payload is queued and replayed by a background sweep — the same workflow run may fire twice for one ticket transition. Design the action so a repeat run is harmless:

  • Include ticket.id or ticket.sequence in any Slack/email body so the recipient can tell two notifications are about the same ticket.
  • Prefer "update if exists" actions over "create" when the destination has its own unique key — most Slack channels and on-call rotations tolerate the rare duplicate; the cost is more than offset by never losing a ticket alert.

Related