Skip to main content

​
Overview

Tickets emit domain events that are published as behavior events (TICKET_*). Journeys can listen to these events on edge triggers, the same way as custom events. Ticket journeys use the ticket as their execution subject. Two tickets associated with the same customer enter and progress independently, and a ticket without a customer can still complete ticket-safe steps.

​
Protected event types

Ticket lifecycle events are internal protected behavior events. They can trigger journeys, but they cannot be emitted from Storefront event endpoints or created as custom event types:
  • TICKET_CREATED
  • TICKET_UPDATED
  • TICKET_PRIORITY_CHANGED
  • TICKET_STAGE_CHANGED
  • TICKET_ASSIGNEE_ADDED
  • TICKET_ASSIGNEE_REMOVED
  • TICKET_RESOLVED
  • TICKET_CLOSED
  • TICKET_REOPENED
  • TICKET_COMMENT_ADDED
  1. Select Ticket as the journey subject.
  2. Select the ticket pipeline this journey manages.
  3. Use TICKET_CREATED as the entry trigger.
  4. Add ticket-safe actions: email to an explicit recipient, change ticket stage, or loop.
  5. Add a New ticket stage condition to TICKET_STAGE_CHANGED, for example New ticket stage is Waiting Customer.
  6. Use Change ticket stage to move the current ticket to an exact stage from the selected pipeline.
Actions that require a customer profile, such as push, in-app, WhatsApp, destination, Braze, and Meta actions, are not available in ticket journeys. Ticket email requires an explicit recipient address and does not depend on a customer association.

​
Ticket stage action

The stage action always targets the ticket that owns the journey execution. It does not update every ticket associated with the same customer or source journey. The pipeline is selected once in the journey settings. Every Change ticket stage action then offers only active stages from that pipeline. The journey stores its pipeline id and each action stores a stable stage code, so renaming a stage does not break the flow. Changing the journey pipeline resets its stage actions to the new pipeline’s default stage.

​
Ticket conditions

When a TICKET_* trigger is selected, the condition editor only exposes the ticket fields available in that event. Order, purchase, RFM, tier, and unrelated customer conditions are hidden because they cannot be evaluated from a ticket lifecycle event. TICKET_CREATED can branch using the ticket data available at creation:
  • title and description
  • priority, status, pipeline, stage, and source
  • customer, assignee, and review presence or identifiers
  • brand, channel, and store identifiers
Lifecycle-specific events add their transition data:
EventAdditional ticket properties
TICKET_UPDATEDchanged field
TICKET_PRIORITY_CHANGEDprevious and new priority
TICKET_STAGE_CHANGEDprevious/new pipeline and stage, plus stage type
TICKET_RESOLVED, TICKET_CLOSED, TICKET_REOPENEDstage transition properties
TICKET_COMMENT_ADDEDcomment ID and internal-comment flag
Priority, status, and source use predefined values. Pipeline and stage values are loaded from the account, so branches do not require internal codes.

​
Event delivery

Ticket lifecycle changes publish protected behavior events (TICKET_*) directly to the events table and enqueue them for journeys. No separate outbox table or custom event type rows are required. The journey queue does not derive routing from a ticket’s existing journey association. Every active ticket journey with a matching trigger can evaluate the event.