Use Copilot to build workflows from a natural language description. Describe what you want to automate and Copilot generates the trigger, steps, and connections for you. Copilot cannot publish workflows directly. After Copilot builds a workflow, open the workflow editor to review and publish it. Create your first workflow Open **Workflows** from your workspace sidebar, select or create a collection, then click **Create Workflow** and give it a descriptive name Select a trigger that defines what event starts your automation. Add filters to ensure the trigger only activates for relevant events, such as specific channels, ticket properties, or custom field values. Connect actions that perform the tasks you want to automate. Set up each action with the appropriate inputs and use dynamic values to reference data from the trigger or previous steps. Use manual triggers to verify each step works correctly, then [publish](/documentation/automate/workflows/publish) to make the workflow active *** Working with triggers and actions Every workflow needs exactly one trigger and at least one action. Triggers respond to events in your workspace, external systems, or run on schedules. Actions perform tasks using information from the trigger and previous steps. **Common trigger types:** * **Ticket triggers**: Activate when tickets are created, updated, assigned, or change status * **Slack triggers**: Respond to reactions or messages in Slack * **Schedule triggers**: Run workflows at specific times or intervals * **Agent triggers**: Allow AI agents to start workflows through natural language rules * **Manual triggers**: Start workflows on demand for testing or batch operations **Common action types:** * **Ticket actions**: Create, update, assign, or manage tickets * **Messaging actions**: Send messages to Slack, email, or other channels * **Integration actions**: Create issues in Jira, Linear, or manage users in Okta * **AI actions**: Summarize tickets, make decisions, or run custom prompts * **Control flow**: Branch execution with conditional logic, wait for events, or loop Integration requirements Some actions require configured integrations. Actions that depend on third-party services show a Setup Required badge. Hover to see which integration is needed, then connect it from your workspace settings. See all available [triggers and actions](/documentation/automate/workflows/triggers-actions) with detailed configuration options *** Converging branches Converging branches merge multiple parallel paths back into a single step. Use them when your workflow branches out for parallel work and then needs to rejoin for a shared next step, like sending notifications through multiple channels before updating a ticket. Connect and disconnect steps

You can only remove individual connections when a step has multiple parents. If a step has a single parent, delete the step itself to remove it from the workflow. Execution behavior ```mermaid theme={"system"} graph TD trigger[Trigger: Ticket created] --> slack[Send Slack message] trigger --> jira[Create Jira issue] slack --> update[Update ticket status] jira --> update style trigger fill:#E2EAEF,stroke:#E2EAEF,color:#000 style slack fill:#E2EAEF,stroke:#E2EAEF,color:#000 style jira fill:#E2EAEF,stroke:#E2EAEF,color:#000 style update fill:#22c55e,stroke:#22c55e,color:#fff ``` **Update ticket status** waits for both **Send Slack message** and **Create Jira issue** to finish before it runs. What happens next depends on how those paths resolved: | Parent path results | Converged step behavior | | ---------------------------- | ------------------------------------------------- | | All parents completed | Executes using data from all paths | | Some completed, some skipped | Executes using data from the completed paths only | | All parents skipped | Skipped | The workflow builder automatically prevents circular dependencies. You cannot create a connection that would cause a step to depend on itself, either directly or through a chain of other steps. *** Data flow and dynamic values Reference data from triggers or previous actions using dynamic values. This lets workflows adapt to the specific event that triggered them. Trigger data Access information from the event that started your workflow, including ticket properties (title, description, priority, status, Display ID, Short ID), requester information (name, email), custom field values, Slack thread data, and timestamps. **Example:** Use ticket priority from the trigger to determine which Slack channel receives a notification. **Example:** Include the Slack thread link in a webhook payload so external systems can link back to the original conversation. Access it via **Ticket > Slack > Thread > Link**. Ticket identifiers Tickets expose three identifiers in the variable picker. Use the one that matches what your downstream system or message expects: | Variable | Example | When to use | | -------------- | ------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | **Display ID** | `BUGZ-123` | Human-readable identifier for messages, emails, and external system references. This is what users see in the Ravenna UI and Slack. | | **Short ID** | `abc12345` | Stable 8-character identifier for URLs, deep links, and API lookups. Useful when you need a compact, unique reference that does not change if the ticket moves channels. | | **Ticket ID** | `clx1a2b3c4d5e6f7g8h9i0j` | Full internal CUID. Use for API calls or integrations that require the canonical identifier. | **Example:** Pass the Display ID into a Slack message body so the recipient sees `BUGZ-123` instead of an internal ID. Access it via **Ticket > Display ID**. **Example:** Append the Short ID to an external URL (`https://example.com/?ref=abc12345`) so you can correlate the ticket later without exposing the channel prefix. Access it via **Ticket > Short ID**. Action outputs Reference results from previous workflow actions, including created ticket IDs, Jira or Linear issue keys, Okta user IDs, Slack thread links, and API response data. **Example:** Add a Jira issue link to the original ticket after creating it. Using the value picker Click a field input in the workflow builder and select from available data sources. Values resolve when the workflow runs. The builder highlights invalid references before you publish. *** Managing steps Right-click any step in the workflow builder to open a context menu with quick actions, or use the step menu (three-dot icon) on the step card. Duplicate a step Copy a single step or an entire branch to reuse configuration: * **Duplicate node** copies the selected step and inserts it directly below the original. Use the context menu or press ⌘ + D (Mac) / Ctrl + D (Windows/Linux). * **Duplicate tree** copies the selected step and all of its downstream steps, preserving the branch structure. Use the context menu or press ⌘ + Shift + D (Mac) / Ctrl + Shift + D (Windows/Linux). Steps inside loops cannot be duplicated. Delete a step Remove steps from the workflow using the context menu or step menu. When deleting a step that has downstream steps, you can choose: * **Delete node** removes only the selected step * **Delete tree** removes the selected step and all of its downstream steps Steps that other parts of the workflow depend on may be protected from deletion. See all [keyboard shortcuts](/documentation/get-started/shortcuts#workflow-builder-shortcuts) including workflow builder shortcuts *** Testing workflows Test workflows before publishing to verify they work correctly. Manually trigger your workflow with test data View detailed logs showing what happened at each step Confirm each action produced the expected results Try different scenarios like missing fields or error conditions Draft workflows can be edited and tested but will not execute automatically. Publish your workflow to make it active. *** Templates Start faster with pre-built templates. Templates provide ready-made workflow structures for common IT operations that you can deploy and customize. When creating a new workflow, browse available templates filtered by tags or search by name Choose a template and click **Create Workflow**. The template is copied to your workspace with a pre-filled name and description. Fill in the step-specific inputs for your organization, such as selecting an Okta application, choosing a Google group, or specifying a Slack channel Test the workflow to verify it works with your configuration, then publish to make it active After deploying a template, you have full control over the workflow. Modify steps, add new actions, change the trigger, remove steps that are not needed, or rename the workflow to match your organization’s terminology. Templates are starting points. *** Tips * **Start simple.** Begin with linear workflows that handle one specific scenario. Add complexity gradually as you confirm each piece works. * **Name steps descriptively.** Clear step names make workflows easier to understand and debug, especially when multiple team members work with them. * **Test with realistic data.** Use data that represents actual conditions. Pay attention to edge cases and error conditions. * **Plan for failures.** Add conditional logic that checks action results. Consider what should happen if external systems are unavailable. * **Keep workflows focused.** Create separate workflows for distinct processes rather than one workflow that handles everything. Learn more about [triggers and actions](/documentation/automate/workflows/triggers-actions), [publishing](/documentation/automate/workflows/publish), and [monitoring workflows](/documentation/automate/workflows/monitor)