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

# Ticket Journey Triggers

> Configure journeys triggered by ticket lifecycle events

## 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`

## Recommended pilot journey

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:

| Event                                                 | Additional ticket properties                     |
| ----------------------------------------------------- | ------------------------------------------------ |
| `TICKET_UPDATED`                                      | changed field                                    |
| `TICKET_PRIORITY_CHANGED`                             | previous and new priority                        |
| `TICKET_STAGE_CHANGED`                                | previous/new pipeline and stage, plus stage type |
| `TICKET_RESOLVED`, `TICKET_CLOSED`, `TICKET_REOPENED` | stage transition properties                      |
| `TICKET_COMMENT_ADDED`                                | comment 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.