Workflows

Workflows are powerful automated processes within the Xurrent IMR platform, designed to enhance incident response, task management, and team communication. By connecting system events to a sequence of actions, workflows enable teams to automate critical operations efficiently.

Accessing Workflows

1. Navigate to the left-side navigation panel
2. Click Workflows
3. Click Create Workflow

Creating a New Workflow

Provide the following details:

• Name: A clear, descriptive name (e.g., "P0 Escalation Workflow")
• Description: Brief explanation of the workflow's purpose
• Team: Select the team to which this workflow applies

How Workflows Work

Workflows are triggered by specific events in the system and execute a series of predefined actions based on configured conditions. They support automation for tasks such as:

• Incident assignment
• Priority adjustments
• Task creation
• Responder notifications
• Email/webhook communications
• Conditional branching and delays

This flexibility allows teams to tailor responses to various scenarios, improving response times and reducing manual effort.

Workflow Structure

A workflow is constructed using four core building blocks

• Trigger: The event that initiates the workflow
 
• Action: The specific tasks or operations performed
 
• Condition: Logic that determines the workflow's path
 
• Delay: A timed pause to allow for resolution or further evaluation  

Building Blocks of Workflows

Triggers

A trigger is the event that starts the workflow, acting as the entry point for automation. Xurrent IMR supports six triggers, so a workflow can respond either to a new incident or to a change on an existing one.

Available Triggers

Incident Created

• Description: Activates the workflow when a new incident is logged in the system. This is the most common starting point for most workflows.
• Example: A workflow triggers when a new incident titled "Server Down" is created, initiating automated steps.
  
  

Incident Status Updated

• Description: Activates when an incident moves from one status to another.
• Configurable: From Status and To Status
• Example: Send a Slack notification to the team when an incident moves from Triggered to Acknowledged.
  
  

Incident Urgency Updated

• Description: Activates when the urgency of an incident changes.
• Configurable: From Urgency and To Urgency (e.g. Low to High)
• Example: Escalate to a senior engineer automatically when urgency is bumped from Low to High.
  
  

Incident Assignee Updated

• Description: Activates when an incident is reassigned to a different user.
• Configurable: From Assignee and To Assignee (defaults to ANY)
• Example: Send an email to the newly assigned engineer with full incident details when ownership changes.
  
  

Incident Team Priority Updated

• Description: Activates when the team priority of an incident changes.
• Configurable: From Priority and To Priority (e.g. P2 to P0 or P1)
• Example: Trigger a major incident workflow and create a Jira ticket when priority escalates from P2 to P0.
  
  

Incident SLA Updated

• Description: Activates when the SLA associated with an incident is updated.
• Configurable: From SLA and To SLA (e.g. SLA SEV1 to SLA SEV0)
• Example: Notify the team manager via email when an incident SLA escalates from SEV1 to SEV0.
  
  

Context Variables

Context variables let you insert incident data into actions such as emails and webhooks. They are available for every trigger.

• {{trigger_data.unique_id}}: Unique identifier (e.g. 550e8400-e29b-41d4-a716-446655440000)
• {{trigger_data.summary}}: Incident summary (e.g. Database connection timeout)
• {{trigger_data.incident_number}}: Sequential number (e.g. 1234)
• {{trigger_data.creation_date}}: Creation timestamp (e.g. 2024-01-15T10:30:00Z)
• {{trigger_data.status}}: Status (1 = triggered, 2 = acknowledged, 3 = resolved)
• {{trigger_data.title}}: Incident title (e.g. Production Database Error)
• {{trigger_data.service}}: Service UUID
• {{trigger_data.urgency}}: Urgency level (0 = low, 1 = high)
• {{trigger_data.assigned_to}}: Assigned user (e.g. john.doe or null)
• {{trigger_data.team_priority}}: Team priority UUID

Example: A workflow triggers when a new incident titled "Server Down" is created, using the "Incident Created" trigger to initiate automated steps.

Actions

Actions are the operational steps executed within the workflow, defining what happens after a trigger. Users can chain multiple actions to handle incidents comprehensively.‍

Available Actions

Change Incident Status

• Parameters: status (required: 1 = Triggered, 2 = Acknowledged, 3 = Resolved)
• Example: {"status": 3} sets the status to "Resolved"
  
  

Change Priority

• Parameters: priority (required, team-defined values)
• Example: {"priority": "P1"} sets priority to "P1"
  
  

Change Escalation Policy

• Parameters: escalation_policy (required, policy ID or name)
• Example: {"escalation_policy": "Default Escalation Policy"} routes to the senior team
  
  

Change Assignee

• Parameters: assignee_username (required)
• Example: {"assignee_username": "Michael"} assigns to "Michael"
  
  

Change Urgency

• Parameters: urgency (required: 0 = Low, 1 = High)
• Example: {"urgency": 1} sets urgency to "High"
  
  

Change Summary

• Parameters: summary (required, new text)
• Example: {"summary": "Updated: Server overload detected"} revises the summary
  
  

Add Note

• Parameters: note (required, text content)
• Example: {"note": "Checking server logs now."} adds a note
  
  

Add Task

• Parameters:
  
  • title (required)
  • description (optional)
  • due_in (optional, minutes)
  • assigned_role (optional, e.g. engineer)

• Example: {"title": "Review Logs", "due_in": 120, "assigned_role": "engineer"} creates a task
  
  

Add Responder

• Parameters: responder_username (required)
• Example: {"responder_username": "Michael"} adds a responder
  
  

Add Stakeholder

• Parameters: stakeholder_email (required)
• Example: {"stakeholder_email": "manager@company.com"} adds a stakeholder
  
  

Add Tag

• Parameters: tags (required, array of strings)
• Example: {"tags": ["database", "production"]} adds tags
  
  

Send Email

• Parameters:
  
  • to (required, email or array)
  • subject (required)
  • message (required, supports templating)
• Example: {"to": "support@company.com", "subject": "Incident: {{trigger_data.title}}", "message": "ID: {{trigger_data.unique_id}}"} sends an email
  
  

Send Webhook

• Parameters:
  
  • url (required)
  • method (required, e.g. POST)
  • headers (optional)
  • body (optional)
• Example: {"url": "https://api.external.com", "method": "POST", "body": "{\"id\": \"{{trigger_data.unique_id}}\"}"} sends a webhook
  ‍

Send Slack

• Parameters:
  
  • Extension (required)
  • Channel (required)
    
    

Notify Create Jira

• Parameters:
  
  • Tenant (required)
  • Project (required)
  • Issue Type (required)
    
    

Conditions

Conditions evaluate logic to branch the workflow, using "left value," "operator," and "right value," with True and False outcomes deciding the next steps.

Supported Operators

• eq: Equal
• neq: Not Equal
• lt: Less Than
• gt: Greater Than
• lte: Less Than or Equal
• gte: Greater Than or Equal
• contains: Contains
• does not contain: Does Not Contain

Parameters

• left_value: the variable to evaluate (e.g. {{trigger_data.urgency}})
• operator: the comparison operator (e.g. eq)
• right_value: the value to compare against (e.g. 1)

Example: A condition checks if the incident status is Resolved: {"left_value": "{{Incident Created.status}}", "operator": "eq", "right_value": 3}. If true, it follows the next step; if false, it proceeds normally.

Delays

A delay pauses the workflow for a specified duration, allowing time for manual intervention or status updates.

Parameters

• delay: number of time units (e.g. 15)
• unit: time unit (minutes or seconds)

Example: A delay of 15 minutes {"delay": 15, "unit": "minutes"} waits before checking if an incident is resolved.

Use Cases and Examples

Use Case 1: Auto-Resolve an Incident

Automates the resolution of minor incidents after a 60-minute window.

Create the Workflow

• Name: "Auto Resolve"
• Description: "Automatically resolves incidents after 60 minutes if unresolved"
• Team: Backend Team

Flow Steps

• Trigger: "Incident Created" initiates the workflow
• Delay: Wait 60 minutes to allow resolution attempts
• Condition: Check if status is not "Resolved" ({{trigger_data.status}} not equal 3)
• Action (True): Update status to "Resolved" ({"status": 3})
  
  

Use Case 2: Major Incident Workflow — P0 Incident Updates

Manages critical P0 incidents with timely updates.

Create the Workflow

• Name: "Major Incident Workflow"
• Description: "Sending updates for P0 incidents"
• Team: API Team

Flow Steps

• Trigger: "Incident Created" starts the process
• Condition: Check if team priority is P0 ({{trigger_data.team_priority}} eq your P0 priority UUID)
• Action (True): Add responder "Michael", then send an email to support@acme.org with subject "P0 Incident Detected: {{trigger_data.title}} (Incident #{{trigger_data.incident_number}})"
• Delay: Wait 15 minutes
• Condition: Check if status is "Resolved" ({{trigger_data.status}} eq 3)
• Action (True): Send resolution email to support@acme.org

Note: The team priority condition uses the priority's UUID, which you can find in your team's priority settings.

Use Case 3: Proactive Monitoring Alert

Automate notifications for incidents requiring immediate attention based on urgency.

Create the Workflow

• Name: "Urgent Alert Workflow"
• Description: "Sends alerts for high-urgency incidents"
• Team: Operations Team

Flow Steps

• Trigger: "Incident Created" starts the workflow
• Condition: Check if urgency is "High" ({{trigger_data.urgency}} eq 1)
• Action (True): Send email to ops@acme.org with urgent alert
• Delay: Wait 10 minutes
• Condition: Check if status is not "Resolved" ({{trigger_data.status}} neq 3)
• Action (True): Add note about ongoing triage, then add stakeholder manager@company.com
  
  

Use Case 4: Security Incident — Delayed SOAR Escalation

Automatically escalates critical P0 security incidents to the SOAR platform.

Create the Workflow

• Name: "SOAR Escalation"
• Description: "Escalates P0 security incidents to SOAR"
• Team: Security Team

Flow Steps

• Trigger: "Incident Created" starts the workflow
• Condition: Check if priority is P0
• Action (True): Add note "Critical security incident detected. Initiating SOAR escalation.", then Send Webhook
• Action (False): Delay 45 minutes, then check if status is still Triggered ({{trigger_data.status}} eq 1); if true, Send Webhook
  
  

Best Practices for Workflows

• Keep Conditions Simple: Use straightforward logic to avoid complex branching
• Monitor Delays: Set reasonable delay times aligned with your team's response expectations
• Document Changes: Clearly describe the workflow's purpose in the description field
• Assign Clear Teams: Ensure proper ownership and permissions for each workflow
• Use Templating: Leverage variables like {{Incident Created.unique_id}} in emails and webhooks
• Chain Actions Logically: Combine multiple actions in a structured sequence
• Test Before Deploying: Verify workflow behaviour with test incidents before enabling for production

Troubleshooting Workflows

Workflow Not Triggering

• Verify the trigger event matches the incident activity
• Check that the workflow is enabled and assigned to the correct team
• Ensure team permissions allow workflow execution

Actions Not Executing

• Review Condition Logic: Ensure left_value, operator, and right_value are correct
• Inspect Action Parameters: Confirm all required fields contain valid values
• Check Variable Syntax: Verify dynamic variables use correct formatting (e.g., {{Incident Created.status}})

Unexpected Delays

• Examine Delay Timing: Verify delay duration aligns with expected behaviour
• Check Condition Branches: Ensure delays are placed in the correct branch of conditional logic

Frequently Asked Questions

What happens if a delay exceeds the incident resolution time? The workflow continues after the delay and checks the latest incident status. If the incident is already resolved, condition logic can prevent unnecessary actions.

Are there limits on the number of actions per workflow? There are no strict limits, but workflows should remain efficient and focused.

Can I edit a workflow after it's created? Yes, changes take effect immediately for new trigger events.

Can workflows trigger other workflows? Yes, if a workflow action updates an incident property (like status or priority), it can trigger another workflow listening for that specific update.

For additional help, contact support with your workflow details and logs.