*** 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 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:** 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. When the destination queue is in a different workspace from the one running the workflow, Ravenna treats it 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 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. **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)