Skip to main content
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 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 and , 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 fires
  • Reassign or escalate a ticket when an assignment reminder 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 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

​
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 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

​
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.
Authentication:The Direct URL contains a unique, unguessable identifier and does not require API keys, signatures, or additional headers to accept a request. Treat the URL itself as a secret: anyone who has it can trigger the workflow.
  • Store the URL in your emitter’s secret manager rather than pasting it into shared documents or public code.
  • If the URL is ever exposed, remove the Webhook trigger and add a new one to rotate to a fresh URL.
  • If the upstream system supports it, restrict egress by IP allowlist on the emitter side.
Outbound calls made later in the workflow (for example, from an HTTP Request action) support API Key, Bearer Token, and Basic Auth using vault-stored credentials.
  • 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 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 . 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 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
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:
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 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 .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 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 and monitoring workflows
Last modified on July 27, 2026