> ## Documentation Index
> Fetch the complete documentation index at: https://darkbanner.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# Ticket

> Create and update tickets for human review, approvals, and task tracking

The **Ticket** node creates or updates a ticket in Zygo's built-in ticketing system. Use it to flag items for human review, build approval workflows, track tasks that result from automated flows, or create audit trails.

## When to Use It

* Flagging an anomaly detected by your flow for human review
* Creating a support ticket from a form submission
* Building approval workflows where a human must act before the flow continues
* Tracking tasks that result from automated processing
* Logging issues when a flow step fails

## Operations

> [tab] Create
>
> Create a new ticket with data from your flow.
>
> **Configuration:**
>
> | Field | Description |
> | - | - |
> | **Title** | The ticket's title. Supports templates. |
> | **Status** | Initial status: `open`, `in_progress`, `resolved`, `closed`. Defaults to `open`. |
> | **Priority** | Priority level: `low`, `medium`, `high`, `critical`. Defaults to `medium`. |
> | **Assignee** | Who the ticket is assigned to. |
> | **Tags** | Tags for filtering and categorization. |
> | **Content** | Structured data attached to the ticket (JSON object). |
> | **Meta** | Additional metadata (JSON object). |
>
> **Example:**
>
> | Field | Value |
> | - | - |
> | Title | `Review: {{1_Form.form_data.name}} — {{1_Form.form_data.subject}}` |
> | Priority | `high` |
> | Assignee | `support-team` |
> | Tags | `form-submission`, `needs-review` |
> | Content | `{"name": "{{1_Form.form_data.name}}", "message": "{{1_Form.form_data.message}}"}` |

> [tab] Update
>
> Update an existing ticket's status, priority, assignee, or metadata.
>
> **Configuration:**
>
> | Field | Description |
> | - | - |
> | **Ticket ID** | The ID of the ticket to update. Typically from a previous node or a query. |
> | **Status** | New status (optional) |
> | **Priority** | New priority (optional) |
> | **Assignee** | New assignee (optional) |
> | **Meta** | Metadata to merge into existing meta (optional) |
>
> Updating the status to `closed` automatically sets the `closed_at` timestamp.

## Output

The Ticket node outputs the created or updated ticket:

| Field | Description |
| - | - |
| `id` | Unique ticket ID |
| `title` | Ticket title |
| `status` | Current status |
| `priority` | Priority level |
| `assignee` | Assigned user or team |
| `tags` | List of tags |
| `content` | Structured content object |
| `meta` | Metadata object |
| `created_at` | Creation timestamp |
| `closed_at` | Close timestamp (if closed) |

Reference in downstream nodes:

```
Ticket created: {{3_Ticket.id}}
Status: {{3_Ticket.status}}
```

## Linking Tickets to Flows

When a Ticket node creates a ticket, it automatically records which flow, run, and node created it:

| Field | Description |
| - | - |
| `flow_id` | The flow that created this ticket |
| `flow_run_id` | The specific run that created it |
| `node_id` | The node that created it |

This lets you trace any ticket back to the exact flow execution that generated it.

## Comments

Tickets support comments for ongoing communication. While the Ticket node itself creates the ticket, comments are typically added through the UI or via the API:

* Team members can discuss the ticket in the comments thread
* Comments include an author name and timestamp
* Use comments for status updates, questions, or resolution notes

## Common Patterns

> [accordion] Error alerting
>
> When a flow step fails, create a ticket for investigation:
>
> 1. **Request node** fails → failure path fires
> 2. **Ticket node** creates a high-priority ticket:
>    * Title: `API failure: {{1_Request.error}}`
>    * Priority: `critical`
>    * Tags: `automated`, `api-error`
>    * Content: Full error details from the failed node

> [accordion] Approval workflow
>
> Route a form submission through human approval:
>
> 1. **Web Form** — User submits a request
> 2. **Ticket node** — Creates a ticket assigned to the approver
> 3. The approver reviews and updates the ticket status in the UI
> 4. A scheduled flow checks for tickets with status `resolved` and continues processing

> [accordion] Form submission tracking
>
> Automatically ticket every form submission for follow-up:
>
> 1. **Web Form** — Customer submits an inquiry
> 2. **Ticket node** — Creates a ticket with all form data in content
> 3. **Request node** — Sends a Slack notification with the ticket ID
>
> This ensures every inquiry is tracked and assigned, with nothing falling through the cracks.

> [accordion] Threshold-based escalation
>
> Monitor a metric and escalate when it exceeds a threshold:
>
> 1. **Request node** (scheduled) — Fetches current metrics
> 2. **Condition node** — Is error rate > 5%?
> 3. **True → Ticket node** — Creates a critical ticket
> 4. **False →** Flow ends (no action needed)

## Ticket Lifecycle

Tickets follow a simple lifecycle through their status field:

```
open → in_progress → resolved → closed
```

| Status | Meaning |
| - | - |
| `open` | New ticket, not yet being worked on |
| `in_progress` | Someone is actively working on it |
| `resolved` | The issue has been addressed |
| `closed` | Ticket is complete and archived |

> [!NOTE]
>
> Status transitions are not enforced — you can move a ticket to any status at any time. The lifecycle above is a recommended convention, not a hard requirement.

> [!TIP]
>
> Use the **Meta** field to store structured data that doesn't fit in the title or content — things like SLA deadlines, external ticket IDs, severity scores, or customer tier. Meta is merged on update, so you can add new fields without overwriting existing ones.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.