> ## Documentation Index
> Fetch the complete documentation index at: https://docs.ravenna.ai/llms.txt
> Use this file to discover all available pages before exploring further.
# Triggers & actions
> Reference for all Ravenna workflow triggers and actions, including ticket events, Slack reactions, integration actions, and configuration details.
Every workflow needs exactly one trigger that starts the automation and one or more actions that perform tasks. This page documents all available triggers and actions.
***
## Triggers
Triggers listen for specific events and provide context to the rest of the workflow.
### Ticket triggers
Fires when new tickets are created. Filter by channel, form, or priority.
**Common use cases:**
* Auto-assign tickets based on form or channel
* Send welcome messages to requesters
* Notify team members of new tickets
* Route tickets to specialized teams
Fires when forms are submitted or when form data is updated on existing tickets. Filter by specific forms.
**Trigger behavior:**
* Fires when a ticket is created with form data
* Fires when form field values are updated on existing tickets
**Common use cases:**
* Route tickets based on submitted form type
* Trigger approval workflows for access request forms
* Send notifications when specific forms are submitted
Fires when categories are assigned or changed on tickets. Filter by specific categories.
**Trigger behavior:**
* Fires when a ticket is created with a category
* Fires when a category is changed on an existing ticket
**Common use cases:**
* Route tickets based on assigned category
* Auto-assign tickets from specific categories to specialized teams
* Escalate tickets when high-priority categories are assigned
Fires when tickets are archived. Use this to clean up related resources or send final notifications.
**Common use cases:**
* Clean up related Slack channels
* Send final status notifications
* Update external tracking systems
Fires when tickets are assigned to users.
**Common use cases:**
* Notify assignees of new assignments
* Update workload tracking systems
* Send assignment confirmation messages
Fires when tickets move between statuses. Filter by channel or assignee.
**Common use cases:**
* Send notifications on status changes
* Update external systems when tickets are resolved
* Trigger follow-up workflows based on status
Fires when tags are added to or removed from tickets.
**Output data:**
* `ticketId` - The ID of the ticket that was updated
* `action.added` - Array of tag IDs that were added
* `action.removed` - Array of tag IDs that were removed
**Common use cases:**
* Escalate tickets when priority tags are added
* Notify teams when specific tags are applied
* Auto-assign tickets based on tag changes
Fires when tickets are approved or declined through approval workflows.
**Common use cases:**
* Continue workflows after approval
* Notify stakeholders of decisions
* Provision access after approval
* Handle declined requests
Fires when an [SLA](/documentation/automate/slas) changes state on a ticket. Use this to react to SLA lifecycle events such as breaches, alerts, attachments, and successful completions.
**Status options:**
* **SLA Attached** - Fires when an SLA is first applied to a ticket. Use this to acknowledge the commitment or notify stakeholders.
* **SLA Alert** - Fires when an SLA alert threshold is crossed, before a breach occurs. Use this for early warnings and escalations.
* **SLA Breached** - Fires when an SLA target is missed. Use this for escalation, reassignment, or stakeholder notifications.
* **SLA Met** - Fires when all SLA targets on a ticket are satisfied. Use this for confirmation messaging or reporting.
**Output data:**
* `ticketId` - The ID of the ticket whose SLA status changed
**Common use cases:**
* Escalate tickets and notify managers when an SLA is breached
* Send early-warning pings to assignees on SLA alerts
* Confirm to requesters when SLA commitments are met
* Apply tags or update priority when an SLA is attached
Fires when a scheduled reminder on a ticket reaches its fire time. Use this to drive follow-up automations when a ticket has been sitting without the expected action.
**Configuration:**
* **Reminder Type** (optional): Limit the trigger to a specific reminder type. Leave empty to fire on any reminder. Supports approval reminders and assignment reminders, which are scheduled automatically when an approver or assignee has not acted within the configured window.
**Output data:**
* `ticketId` - The ID of the ticket the reminder was attached to
* `reminderType` - The type of reminder that expired (`Approval` or `Assignment`)
**Common use cases:**
* Nudge approvers in Slack or email when an [approval reminder](/documentation/tickets/reminders) fires
* Reassign or escalate a ticket when an [assignment reminder](/documentation/tickets/reminders) fires
* Post a private note on the ticket summarizing pending approvers
Fires when an entitlement changes status. An entitlement is an individual access grant to a user for a specific user group, created when an [access request](/documentation/manage-access/overview) is approved.
**Configuration:**
* **Statuses** (required): Select one or more entitlement statuses to trigger on. A single rule can fan out across multiple outcomes, so you do not need to duplicate the trigger for each status.
* **Access Provisioned** - The user was successfully granted access.
* **Access Deprovisioned** - The user's access was successfully removed.
* **Provision Failed** - Granting access failed.
* **Deprovision Failed** - Removing access failed.
* **Skipped Provisioning** - Provisioning was skipped (for example, the user already had access).
* **Skipped Revocation** - Revocation was skipped (for example, another active grant still requires the access).
**Output data:**
* `ticketId` - The ID of the access request ticket that owns the entitlement
* `entitlementId` - The ID of the entitlement whose status changed. Expand it to read `applicationId`, `accessLevelId`, `userGroupId`, `userId`, and `entitlementStatus`.
**Common use cases:**
* Notify the requester when their access is provisioned
* Alert the IT team when provisioning or deprovisioning fails
* Fan out one workflow across **Access Provisioned**, **Deprovision Failed**, and **Skipped Provisioning** together
Learn more about [access requests and entitlements](/documentation/manage-access/overview)
### Task triggers
Fires when individual tasks within a task template are marked as completed. Provides access to both the completed task and the next task in the sequence for creating handoffs.
**Output data:**
* `ticketId` - The ID of the ticket containing the task
* `taskItemId` - The ID of the completed task item
* `currentTask` - Information about the task that was just completed
* `nextTask` - Information about the next task in the sequence (if any)
* `currentTaskAssigneeIds` - User IDs of assignees on the completed task
* `nextTaskAssigneeIds` - User IDs of assignees on the next task
* `hasMoreTasks` - Boolean indicating if there are more tasks remaining
**Common use cases:**
* Notify next task assignees when their task becomes active
* Send completion notifications to stakeholders
* Create task handoffs between team members
* Escalate if tasks are completed outside SLA windows
Fires when a task template is applied to a ticket. Use this to kick off workflows that depend on structured task lists being attached to tickets.
**Common use cases:**
* Notify assignees when a task template is applied
* Trigger onboarding or checklist workflows
* Set ticket status or priority based on the applied template
### Message triggers
Fires when messages are added to tickets.
**Configuration:**
* **Message Authors** (optional): Limit the trigger to messages from specific users or groups.
* **Visibility** (optional): Restrict the trigger to either `Public` or `Private` messages. Leave unset to fire on both.
* **Public**: Messages visible to requesters and external channels.
* **Private**: Internal-only [private notes](/documentation/tickets/private-notes) that stay hidden from requesters.
* **Filters** (optional): Add filter groups to match on additional message or ticket attributes.
**Common use cases:**
* Analyze message content or sentiment
* Notify team members of updates
* Trigger automated responses
* Route only public replies to customer-facing workflows, or only private notes to internal review flows
### Agent triggers
Allows AI agents to trigger workflows through natural language rules. Reference a workflow using `@Workflow Name` in an agent rule to let the agent execute it.
**How it works:**
1. Create a workflow with an Agent Trigger
2. Optionally configure a form to collect required information
3. Reference the workflow in your agent's rules using `@Workflow Name`
4. The agent triggers the workflow when conditions in the rule are met
**Configuration:**
* **Form (optional)**: Select a form to collect structured information before the workflow runs.
* **With a form:** The agent pre-fills form fields from conversation context and presents the form for user review before submission. The form must be **Published** — Draft and Archived forms are skipped at runtime, and the agent falls back to the no-form confirmation flow.
* **Without a form:** The agent shows a confirmation button so the user can approve before the workflow runs. To skip confirmation, add explicit auto-trigger language to the agent rule (for example, "automatically run the workflow without asking for confirmation").
* **Agents**: Select which agents have access to trigger this workflow
**Example rule:**
When a user requests software access, ask which application they need and
their business justification. Then trigger @Workflow - Software Access Request
with the details provided.
Agents must have explicit access to workflows. Reference workflows in rules using `@` mentions to grant access.
### Scheduled triggers
Runs workflows on a recurring schedule defined by a standard cron expression.
**Configuration:**
* **Schedule** - A standard 5-field cron expression (`minute hour day-of-month month day-of-week`). Use the inline picker to build common schedules, or type an expression directly. Examples:
* `0 * * * *` - Every hour, on the hour.
* `0 9 * * 1-5` - 9:00 AM, Monday through Friday.
* `0 0 1 * *` - Midnight on the first day of each month.
* `*/15 * * * *` - Every 15 minutes.
* **Timezone** - The timezone the schedule runs in. Defaults to UTC. Choose from regions including US, Europe, Asia Pacific, and other Americas.
**Common use cases:**
* Schedule recurring reports or cleanup tasks
* Automate periodic ticket reviews
* Run time-based processes
Cron-triggered workflows have no ticket context, so they cannot reference ticket fields. Use them for batch operations, reports, or system maintenance.
### Webhook triggers
Starts a workflow when an external system posts to a unique webhook URL. The trigger uses an AI prompt to parse the incoming request body into structured fields that downstream steps can reference.
**How it works:**
1. Add the Webhook trigger to a workflow.
2. Copy the generated **Direct URL** and configure it as the destination in the emitting system.
3. Write a **Prompt** that describes how to transform the incoming payload into the fields you need downstream.
4. When the external system posts to the URL, Ravenna runs the prompt against the request body and starts the workflow with the parsed output.
**Configuration:**
* **Direct URL** - Read-only URL to register with the upstream webhook emitter. Click to copy.
* **Prompt** - Instructions for transforming the incoming webhook body into structured data for downstream actions.
* **Webhook response HTTP status code** - Status code Ravenna returns to the emitter once the run is accepted. Choose the value the emitter expects:
* `200 OK` (default) - Generic success.
* `201 Created` - Emitter expects a "created" acknowledgment.
* `202 Accepted` - Emitter expects an asynchronous acceptance signal.
* `204 No Content` - Emitter expects an empty body response.
Set this to match what the upstream system requires for a successful delivery. Some webhook providers retry or disable the endpoint if they receive an unexpected status, so pick the code their documentation specifies.
**Common use cases:**
* Receive events from systems without a native Ravenna integration
* Bridge custom internal tools into workflow automation
* Trigger workflows from monitoring or alerting platforms
### Third-party integration triggers
Many integrations provide workflow triggers for events in their systems.
See the [Integrations overview](/integrations/overview) to explore available triggers and actions for each integration
***
## Actions
Actions perform work in your workflows using information from triggers and previous actions.
### Ticket actions
Creates a new ticket with configurable properties like title, description, channel, priority, and tags. Use trigger data to populate ticket details.
**Cross-workspace creation:**
Select any queue you have access to, including queues in other workspaces. If the destination queue is in a different workspace, Ravenna treats this as a cross-workspace create and publishes the ticket immediately. Triggers, notifications, and downstream workflows in the destination workspace fire as if the ticket were created normally. Same-workspace creates continue to skip downstream dispatch to prevent the workflow from retriggering itself.
**Common use cases:**
* Create follow-up tickets for multi-step processes
* Generate tickets from Slack messages or external events
* Split complex requests into multiple tickets
* Hand off work to another team's workspace and let their automations pick it up
Modifies existing tickets by changing properties like priority, tags, status, assignee, requester, parent ticket, or custom fields.
**Common use cases:**
* Escalate tickets by changing priority
* Add processing or status tags
* Update custom fields based on workflow logic
* Set a parent ticket to organize tickets into a hierarchy
* Reassign the requester when a ticket is submitted on behalf of someone else
Changes ticket status with optional resolution notes.
**Common use cases:**
* Auto-resolve tickets meeting specific criteria
* Move tickets through workflow stages
* Add resolution notes automatically
Updates ticket priority based on workflow conditions.
**Common use cases:**
* Escalate urgent issues automatically
* Adjust priorities based on SLA requirements
* Reprioritize based on ticket content analysis
Assigns tickets to specific users or groups. When you select a group, it is automatically expanded to its individual members when the workflow runs.
**Assignment strategy:**
* **All**: Assigns every selected user (or every member of the selected group) to the ticket.
* **Round Robin**: Assigns one user from the selected list or group using rotation to balance workload.
**Round Robin rotation scope:**
Each Add Assignee step keeps its own independent rotation. If a workflow has multiple Add Assignee steps configured with Round Robin, each step rotates through its assignees on its own counter. Two steps that share the same user list assign in parallel rotations rather than continuing a single shared rotation. This lets you stage hand-offs (for example, a triage assignee and a follow-up reviewer) without one step skipping members of the other step's group.
**Common use cases:**
* Distribute tickets across a group with Round Robin for load balancing
* Assign based on expertise or tags
* Route tickets to specific groups or teams
* Stage multiple Round Robin assignments (triage, then review) within a single workflow without interfering rotations
Adds followers to tickets to keep stakeholders informed. Select from Ravenna members or groups, including groups synced from third-party integrations.
**Common use cases:**
* Add managers to high-priority tickets
* Include cross-functional stakeholders
* Notify relevant parties automatically
Adds approvers to a ticket and creates an approval round. Select from Ravenna members or groups.
**Assignment strategy:**
* **All**: Assigns everyone in the selected list as approvers. Any one of them can approve.
* **Round Robin**: Assigns one approver from the list using rotation to balance workload.
* **Auto**: System bot auto-approves immediately (use for conditional approval branches).
**Common use cases:**
* Route approvals to managers with load balancing via Round Robin
* Add all qualified approvers and let the first available person approve
* Assign approvers by department using Round Robin for fair distribution
Pauses workflow execution until the ticket's approval rounds complete or the configured timeout expires. The step branches into three outcome paths: **On Approved**, **On Declined**, and **On Timeout**.
**Configuration:**
* **Duration**: Maximum time to wait for a response before falling through to the **On Timeout** branch. Default is 3 days. Accepts values like `1h`, `2d`, `1w`, or `Forever` to wait indefinitely.
**Behavior with assignment strategies:**
* **Auto**: Workflow continues immediately down **On Approved** (auto-approved by system bot)
* **All**: Waits for any one of the assigned approvers to respond
* **Round Robin**: Waits for the single assigned approver to respond
* Honors the assignment strategy set by preceding "Add Approvers" actions
**Output data:**
* `isApproved` - Boolean indicating whether the ticket was approved
* `isTimedOut` - Boolean indicating whether the wait expired before a response was received
**Branch logic:**
* **On Approved** runs when `isApproved` is `true`.
* **On Declined** runs when `isApproved` is `false` and `isTimedOut` is `false`.
* **On Timeout** runs when `isTimedOut` is `true`. Use this branch to send escalation reminders, reassign approvers, or close the ticket as expired.
**Common use cases:**
* Gate access provisioning until approved
* Escalate to a backup approver when the primary does not respond in time
* Auto-close stale approval requests after a deadline passes
Pauses workflow execution until specific users send messages on a ticket. Automatically excludes workflow-generated and AI-generated messages.
**Configuration:**
* **Message Authors**: Select users or groups whose messages resume the workflow
* **Timeout Duration**: Maximum wait time (default: 3 days, supports "1h", "2d", "1w")
* **Message Sources** (optional): Filter by Web, Email, or Slack. If not specified, all sources are accepted.
**Output data:**
* `isSuccess` - Boolean indicating if a matching message was received before timeout
* `ticketMessageId` - The ID of the message that resumed the workflow (if successful)
**Common use cases:**
* Wait for customer responses before proceeding
* Pause until specific team members provide input
* Hold workflow until user confirms information
Adds tags to tickets for categorization and filtering.
**Common use cases:**
* Auto-tag based on content analysis
* Categorize by form type
* Add processing status tags
Relocates tickets between workspaces, channels, or statuses. Supports cross-workspace moves while maintaining ticket history and context.
**Common use cases:**
* Transfer tickets between teams
* Escalate to different departments
* Move tickets across workspaces
Shares a ticket to a destination queue in another workspace. Unlike Move Ticket, the original ticket stays in its current queue and a shared reference is created in the destination. Select a workspace first, then select a queue within that workspace.
**Common use cases:**
* Give another team visibility into a ticket without transferring ownership
* Share requests across departments for collaborative resolution
* Broadcast tickets to multiple queues for cross-team awareness
Sends customer satisfaction surveys to users after ticket resolution.
**Common use cases:**
* Survey after ticket resolution
* Measure service quality
* Gather user feedback
Monitors tickets until specific conditions are met, then continues workflow execution.
**Common use cases:**
* Wait for status changes before proceeding
* Monitor for specific ticket updates
* Trigger actions when conditions are met
Pauses workflow execution until a ticket has been inactive for a specified duration. Helps keep channels clean and SLAs on track.
**Common use cases:**
* Auto-resolve tickets after inactivity period
* Send reminder messages before auto-closing
* Escalate tickets with no response
Sends new messages on tickets.
**Common use cases:**
* Send automated updates to requesters
* Request additional information
* Provide automated status notifications
Checks if there are any new messages on a ticket since the last check.
**Common use cases:**
* Detect user responses in monitoring workflows
* Track conversation activity
* Trigger actions when new messages appear
Attaches links to external resources on the original Ravenna ticket. Maintains references to related external resources for visibility and audit trails.
**Input fields:**
* `ticketId` - The Ravenna ticket to attach the link to
* `name` - Descriptive name for the link (e.g., "Related Jira Issue")
* `url` - The external URL to link to
**Output data:**
* `isSuccess` - Boolean indicating if the link was created successfully
* `ticketLinkId` - The ID of the created ticket link
* `ticketId` - The ID of the linked ticket
* `url` - The URL that was linked
**Common use cases:**
* Link to external tickets in other systems (Jira, Linear, GitHub Issues)
* Reference related Slack channels created for incidents
* Create audit trails for external resource creation
Publishes a newly created ticket, making it visible and triggering any associated notifications. Use after creating a ticket when you need to control the timing of publication separately from creation.
**Common use cases:**
* Create and configure a ticket across multiple steps before making it visible
* Control when notifications are sent for new tickets
* Finalize ticket properties before publishing
Imports a task template into a ticket, attaching a structured checklist of tasks. The template's tasks, assignees, and ordering are applied to the ticket.
**Common use cases:**
* Attach onboarding checklists to new hire tickets
* Apply standard operating procedures to incident tickets
* Add review checklists based on ticket type or category
Searches for tickets matching specified criteria. Returns matching tickets that can be referenced in downstream workflow steps.
**Common use cases:**
* Find related or duplicate tickets
* Look up tickets by requester, status, or custom fields
* Check for existing tickets before creating new ones
Searches for users in your organization matching specified criteria. Returns a list of user IDs that downstream steps can reference (for example, to add assignees, followers, or approvers, or to iterate over with Loop).
**Configuration:**
* **User Filter**: One or more filter groups that define which users to return. Filter on user attributes such as name, email, or group membership. Ravenna combines groups with OR and combines conditions inside a group with AND.
* **Limit**: Maximum number of users to return (default 50, maximum 50).
**Output data:**
* `userIds` - Array of user IDs matching the filter
**Common use cases:**
* Look up the members of a group or team to notify or assign
* Find users by attribute for routing decisions
* Build a dynamic recipient list for downstream Add Assignee, Add Followers, or Send Email steps
* Combine with Loop to run actions per matching user
### Control flow actions
**Duration units** accepted by `Wait` and other duration fields:
| Unit | Accepted values |
| ------ | --------------------------------- |
| Years | `years`, `year`, `yrs`, `yr`, `y` |
| Months | `months`, `month`, `mo` |
| Weeks | `weeks`, `week`, `w` |
| Days | `days`, `day`, `d` |
| Hours | `hours`, `hour`, `hrs`, `hr`, `h` |
Pauses workflow execution for a specified duration.
**Common use cases:**
* Add delays between actions
* Wait for external processes to complete
* Create timed follow-ups
Pauses workflow execution until a specific date or a date relative to a target. Use this to schedule actions around key dates like onboarding, license renewals, or contract deadlines.
**From date:**
* The target date the wait calculates from.
* Accepts a fixed date or a [dynamic value](/documentation/automate/workflows/workflow-builder#data-flow-and-dynamic-values) from the trigger or a previous step (for example, a date field from a form submission or an action output).
* Use a dynamic value when the date depends on ticket data, such as an access start date or a contract end date provided at runtime.
**Offset scheduling:**
* Set an optional offset to run the workflow relative to the From date.
* Positive offsets (e.g., `5d`) wait until after the From date.
* Negative offsets (e.g., `-5d`) wait until before the From date.
* Example: an offset of `-5d` on an onboarding date of March 20 resumes the workflow on March 15.
**Common use cases:**
* Send reminders before a deadline or renewal date
* Trigger onboarding tasks relative to a start date
* Schedule follow-ups after a target date
* Coordinate multi-step processes around key milestones
Evaluates conditional expressions to branch workflow logic.
**Common use cases:**
* Branch workflow logic based on ticket properties
* Filter actions by conditions
* Implement decision trees
Provides if/else branching to execute different actions based on conditions.
**Common use cases:**
* Execute different actions based on ticket properties
* Handle multiple scenarios with alternative paths
* Create conditional workflow branches
Jumps to a specific step in the workflow.
**Common use cases:**
* Create workflow loops
* Skip steps based on conditions
* Implement retry patterns
Iterates through a collection of items, executing the contained actions for each item. Use loops to process lists of users, tickets, or other data sets within a workflow.
**Common use cases:**
* Process multiple items from a search result
* Send notifications to a list of users
* Perform bulk operations across a set of tickets
### AI actions
Generates a concise summary of a ticket's conversation history, capturing what happened, what was decided, and what outcomes were achieved.
**Common use cases:**
* Generate ticket summaries for handoffs
* Create executive briefings
* Summarize resolution steps
Evaluates conditions that require contextual analysis beyond simple rule-based logic. The workflow continues down one of two paths based on the AI's decision.
**Common use cases:**
* Route tickets based on content analysis
* Evaluate sentiment for escalation
* Determine appropriate next actions
Runs AI reasoning with custom instructions to analyze context, generate responses, or make decisions within the workflow.
**Common use cases:**
* Draft response messages based on ticket content
* Extract structured data from unstructured text
* Analyze sentiment or urgency from messages
* Generate dynamic next steps from conversation history
### Messaging actions
Sends an email to specified users. Configure recipients, subject, and body content with dynamic values from the workflow.
**Body formatting:**
The body field is a rich text editor. Use the formatting toolbar to add **bold**, *italic*, lists, links, and headings. Type formatted text directly in the editor instead of pasting raw HTML or Markdown. Insert dynamic values from earlier workflow steps to personalize each send.
**Recipients added as followers:**
When this action sends an email from a ticket, Ravenna automatically adds the recipients as followers on that ticket. This keeps them in the loop on future agent replies. Both resolved Ravenna users and extra email addresses that map to users in your organization are included.
* Existing followers, approvers, the requester, assignee, and author are skipped.
* Email addresses that don't match a Ravenna user are ignored.
* Followers are not added when the ticket is marked as private.
* If adding followers fails, the email is still sent and the error is logged.
**Common use cases:**
* Notify external stakeholders who are not in Slack
* Send formal communications like approval confirmations or access grants
* Deliver summary reports or status updates via email
* Loop additional teammates into a ticket by emailing them from a workflow
### Tools actions
Calls external APIs to integrate with third-party services. Supports authentication using credentials stored in your organization's Vault.
**Configuration:**
* **URL** - The API endpoint to call
* **Method** - HTTP method: GET, POST, PUT, DELETE, or PATCH
* **Headers** - Custom key-value headers to include in the request
* **Query parameters** - Key-value pairs appended to the URL
* **JSON body** - Request body content (for POST, PUT, PATCH, DELETE)
* **Timeout** - Maximum wait time for a response (default: 10 seconds, max: 45 seconds)
**Authentication methods:**
* **None** - No authentication
* **API Key** - Sends an API key in a configurable header (default: `X-API-Key`). Select a vault credential to provide the key value.
* **Bearer Token** - Sends a token in the `Authorization: Bearer` header. Select a vault credential to provide the token value.
* **Basic Auth** - Sends a username and password as a Base64-encoded `Authorization: Basic` header. The password field supports vault credentials.
**Output data:**
* `isSuccess` - Boolean indicating if the response status code is 2xx
* `Response.Body` - The response body from the API
* `Response.StatusCode` - The HTTP status code
**Common use cases:**
* Send data to external systems
* Fetch information from third-party APIs
* Trigger actions in other platforms
* Integrate with services that lack a native Ravenna integration
### Third-party integration actions
Many integrations provide workflow actions for automating tasks in their systems.
See the [Integrations overview](/integrations/overview) to explore available triggers and actions for each integration
***
## Tips
* **Use specific trigger filters.** Narrow triggers with channel, priority, status, or user criteria to avoid unnecessary executions.
* **Make actions idempotent.** Configure actions so they can be safely repeated without causing problems. This improves reliability when workflows retry after failures.
* **Name steps clearly.** Descriptive names make workflows easier to understand and debug.
* **Test with realistic data.** Pay attention to edge cases and error conditions.
* **Document non-obvious logic.** Add descriptions explaining business rules so team members understand why workflows behave in certain ways.
Learn more about [building workflows](/documentation/automate/workflows/workflow-builder) and [monitoring workflows](/documentation/automate/workflows/monitor)
## Trigger selection guide
### Ticket lifecycle triggers
| Trigger | When it fires | Best for |
| -------------------------- | ----------------------------------------------------------- | ------------------------------------------------------------- |
| Ticket Created | New ticket appears | Initial routing, notifications, external system sync |
| Form Submitted | Form data submitted or updated on a ticket | Structured request processing, approval flows |
| Category Assigned | Category set or changed | Category-based routing, team assignment |
| Ticket Status Changed | Status transitions | Status-based notifications, follow-up actions |
| Ticket Assigned | Assignee added | Assignment notifications, workload tracking |
| Ticket Archived | Ticket archived | Cleanup, final notifications, external sync |
| Ticket Tags Changed | Tags added or removed | Tag-based routing, escalation triggers |
| Ticket Approval | Approval decision made | Post-approval provisioning, decline handling |
| SLA Status | SLA attached, alerting, breached, or met | SLA escalations, early-warning notifications, breach handling |
| Reminder Expired | A scheduled reminder on a ticket fires | Approval nudges, escalation of stale approvals |
| Entitlement Status Changed | An entitlement's provisioning status changes | Access request provisioning notifications, failure handling |
| Message Sent | New message on ticket (filterable by author and visibility) | Response monitoring, sentiment analysis, private-note routing |
| Task Completed | Task item completed | Task handoffs, sequential workflow progression |
| Task Template Applied | Task template applied to a ticket | Onboarding workflows, checklist-driven processes |
### Other triggers
| Trigger | When it fires | Best for |
| ---------------------- | --------------------------------------------- | -------------------------------------------------------- |
| Slack Reaction Added | Emoji reaction added in Slack | Ticket creation from reactions, acknowledgment tracking |
| Slack Reaction Removed | Emoji reaction removed | Undo or cleanup workflows |
| Agent Trigger | Agent initiates via rule | Agent-to-workflow handoff, form-based requests |
| Cron | Recurring schedule | Periodic reports, stale ticket cleanup, batch operations |
| Webhook | Inbound HTTP POST to the trigger's Direct URL | Bridging external systems without a native integration |
Microsoft Teams reaction triggers are not yet exposed as workflow triggers. Teams uses a fixed 5-reaction set ([emoji actions](/integrations/microsoft-teams/emoji-actions)) that drive built-in ticket actions but are not available as custom workflow triggers in the current beta.
### Trigger selection tips
* **Ticket Created vs Form Submitted:** Use Ticket Created for broad routing. Use Form Submitted when you need to react to specific form types or when form field values drive the workflow logic.
* **Form Submitted fires on updates too.** If form field values are changed on an existing ticket, Form Submitted fires again. Design workflows to handle re-triggers gracefully.
* **Category Assigned fires on creation too.** If a ticket is created with a category already set, this trigger fires. You do not need both Ticket Created and Category Assigned for the same workflow.
* **Tags Changed provides add/remove context.** The trigger output includes which tags were added and which were removed, so you can branch on whether a specific tag was added vs. removed.
* **Task Completed includes next-task info.** The output includes the next task in the sequence and its assignees, making it ideal for handoff notifications without additional lookups.
* **Cron triggers have no ticket context.** Cron-triggered workflows cannot reference ticket fields. Use them for batch operations, reports, or system maintenance tasks.
### Trigger filters
All triggers support filters that narrow when the workflow activates. Filters use AND logic: all conditions must be true for the trigger to fire. If you need OR logic, create separate workflows for each condition.
***
## Action selection guide
### Ticket management
| Action | What it does | When to use |
| ------------------- | ----------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------- |
| Create Ticket | Creates a new ticket in any workspace you have access to | Follow-up tickets, splitting requests, ticket generation from events, cross-workspace handoffs |
| Update Ticket | Modifies ticket properties including requester and parent ticket | Adding context, changing fields, setting parent-child relationships |
| Set Status | Changes ticket status | Auto-resolution, stage progression |
| Set Priority | Changes ticket priority | Auto-escalation, SLA-based priority adjustment |
| Add Assignee | Assigns users or groups | Routing, load balancing with Round Robin |
| Add Followers | Adds followers to ticket | Stakeholder notification, cross-team visibility |
| Add Approvers | Creates an [approval round](/documentation/tickets/approvals/rounds) with approvers | Approval flow setup |
| Add Tags | Adds tags to ticket | Categorization, processing markers |
| Move Ticket | Moves ticket between workspaces or channels | Cross-team transfers, department escalation |
| Share Ticket | Shares ticket to a queue in another workspace | Cross-team visibility, collaborative resolution |
| Send Message | Sends a message on ticket | Status updates, requesting information |
| Link Ticket | Attaches external URL to ticket | Linking Jira/Linear issues, audit trails |
| Publish Ticket | Publishes a newly created ticket | Controlling notification timing, multi-step ticket setup |
| Apply Task Template | Applies a task template to a ticket | Onboarding checklists, standard operating procedures |
| Search Tickets | Finds tickets matching criteria | Duplicate detection, related ticket lookup, bulk operations |
| Search Users | Finds users matching filter criteria | Dynamic recipient lists, group member lookup, attribute-based routing |
| Send CSAT | Sends satisfaction survey | Post-resolution feedback collection |
### Wait and monitoring
| Action | What it does | When to use |
| ---------------------- | --------------------------------------------- | --------------------------------------------------------- |
| Wait | Pauses for a duration | Delays between actions, timed follow-ups |
| Wait Until | Pauses until a specific date and time | Calendar-based deadlines, date-driven actions |
| Wait for Approval | Pauses until approved, declined, or timed out | Approval gates with timeout fallback for stalled requests |
| Wait for Message | Pauses until a message is received | Waiting for user input or confirmation |
| Wait for Inactivity | Pauses until ticket is inactive | Auto-resolution after no activity |
| Monitor Ticket | Watches for conditions | Waiting for specific ticket state changes |
| Check for New Messages | Checks for recent messages | Detecting responses in polling-style workflows |
### Control flow
| Action | What it does | When to use |
| ----------- | ----------------------------- | --------------------------------------------------------------- |
| Conditional | Evaluates expressions | Branching based on data values |
| If / Else | Binary branching | Simple true/false path selection |
| Goto | Jumps to another step | Retry patterns, skipping steps |
| Loop | Iterates through a collection | Processing search results, bulk notifications, batch operations |
### AI actions
| Action | What it does | When to use |
| ----------------- | -------------------------------- | --------------------------------------------------------- |
| Summarize Ticket | Generates a conversation summary | Handoff summaries, executive briefings |
| AI Decision Maker | AI-powered branching | Content analysis, sentiment-based routing, complex triage |
| Custom Prompt | Runs custom AI reasoning | Data extraction, response drafting, dynamic analysis |
### Messaging
| Action | What it does | When to use |
| ---------- | ------------------------------ | --------------------------------------------------------- |
| Send Email | Sends email to specified users | External stakeholder notifications, formal communications |
### Tools
| Action | What it does | When to use |
| ------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------- |
| HTTP Request | Calls external APIs with configurable URL, method, headers, query params, JSON body, timeout, and auth (None, API Key, Bearer, Basic). Auth fields support vault-stored credentials. Returns isSuccess, Response.Body, Response.StatusCode. | Custom integrations without native actions, external API calls, webhook triggers |
***
## Action selection tips
* **Add Assignee supports Round Robin.** When assigning from a group, Round Robin distributes evenly across members. Use "All" when every member of the group should be assigned.
* **Round Robin rotates per step, not per workflow.** Each Add Assignee step has its own rotation counter. A workflow with two Round Robin Add Assignee steps maintains two independent rotations, even when both reference the same group.
* **Add Approvers + Wait for Approval work together.** Add Approvers creates an [approval round](/documentation/tickets/approvals/rounds) with the selected approvers. Wait for Approval pauses execution until the round completes. The wait step honors the assignment strategy: All means any one approver can respond, Round Robin means the specific assigned approver must respond.
* **Wait for Approval with Auto strategy** approves immediately (system bot). Use this for workflows where approval is conditional and only required in some branches.
* **Wait for Approval has a configurable timeout.** Default is 3 days. The step branches into On Approved, On Declined, and On Timeout. Always design the On Timeout path (escalation, auto-close, or notify) so stalled approvals do not leave the workflow stuck.
* **Wait for Message filters by author and source.** You can specify which users' messages resume the workflow and which channels (Web, Email, Slack) count. Workflow-generated and AI-generated messages are automatically excluded.
* **Wait for Message has a configurable timeout.** Default is 3 days. Always plan for both success and timeout paths.
* **Prefer native integration actions over HTTP Request.** Native actions (Jira, Okta, Linear, etc.) handle auth, error handling, and output parsing. Use HTTP Request only when no native action exists.
* **AI Decision Maker is for judgment calls, not data checks.** Use Conditional or If/Else for checking field values. Use AI Decision Maker when the decision requires interpreting content, sentiment, or context.
* **Custom Prompt is versatile.** Use it to extract structured data from unstructured text, draft responses, analyze sentiment, or generate dynamic content. Its output can drive downstream conditional logic.
* **Link Ticket creates bidirectional traceability.** After creating an external issue (Jira, Linear), use Link Ticket to attach the URL back to the Ravenna ticket. This makes it easy to navigate between systems.
* **Goto enables retry patterns.** Use Goto with a conditional to create retry loops (e.g., check condition, then if not met: wait, then goto the check step again). Be cautious of infinite loops.
* **Loop + Search Tickets work together.** Use Search Tickets to find a set of matching tickets, then Loop to process each result (send notifications, update fields, etc.).
* **Search Users feeds downstream people steps.** Pipe the `userIds` output into Add Assignee, Add Followers, Add Approvers, or Send Email to build dynamic recipient lists. Combine with Loop to act on each user individually.
* **Wait vs Wait Until.** Wait pauses for a relative duration ("2 hours"). Wait Until pauses until an absolute date and time. Use Wait Until when the timing depends on a date from ticket data (e.g., a start date form field).
* **Apply Task Template attaches structured checklists.** Combine with the Task Completed trigger on a separate workflow to create handoff chains between task assignees.
* **Send Email for external stakeholders.** Use Send Email when recipients are outside Slack or need formal email communications. For internal team notifications, prefer Slack messages.
***
## Data flow between steps
Every trigger and action produces output data that downstream steps can reference.
* **Trigger data** includes the full event context: ticket properties, requester info, custom field values, timestamps, and event-specific data (e.g., which tags changed, which task completed).
* **Action output** varies by action type: created ticket IDs, API response data, success/failure indicators, AI-generated text.
* **Scope:** A step can reference data from any step that is a direct ancestor in the workflow graph. Steps in parallel branches cannot reference each other's data.
* **Converging steps** have access to data from all completed parent branches.
***
## Constraints
* **Trigger filters use AND logic.** All filter conditions must be true. For OR logic, create separate workflows.
* **One trigger per workflow.** You cannot have multiple triggers on a single workflow.
* **Assignment strategies are set per action.** Add Assignee and Add Approvers each independently support All or Round Robin. Round Robin rotation state is also tracked per Add Assignee step, so multiple Add Assignee steps in the same workflow do not share a rotation counter.
* **Wait for Approval inherits the strategy** from the preceding Add Approvers action.
* **Wait for Message excludes automated messages.** Workflow-generated and AI-generated messages do not count as matching messages.