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

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}}"}

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

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

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

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.

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

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.

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.