Overview
Workflows are the core of EasyAlert Automation. A workflow is a visual graph of nodes (trigger, actions, conditions, etc.) connected by edges that define the execution flow. You build workflows in a drag-and-drop designer, publish versioned snapshots, and activate them to respond to events automatically.Drag-and-Drop Designer
Build workflows visually with a ReactFlow-based canvas. Drag nodes from the palette, connect them with edges, and configure each node in the inspector panel.
Version Control
Every publish creates an immutable version snapshot. Compare versions with the built-in diff viewer and rollback to any previous version.
Template Gallery
Start from pre-built templates for common scenarios — auto-remediation, notification routing, Kubernetes management, and more.
Clone & Rollback
Duplicate existing workflows with one click. Rollback to any published version if something goes wrong.
Creating a Workflow
Choose a Starting Point
Select a template from the gallery for common scenarios, or choose Blank Workflow to start from scratch.
Name and Describe
Enter a descriptive Name (e.g., “Auto-Restart Critical Services”) and optional Description explaining when and why this workflow should run.
The Workflow Designer
The designer has four main areas:| Area | Location | Purpose |
|---|---|---|
| Node Palette | Left sidebar | Drag node types onto the canvas |
| Canvas | Center | Visual workspace — arrange and connect nodes |
| Inspector | Right panel | Configure the selected node’s settings |
| Toolbar | Top bar | Save, Publish, Undo/Redo, Auto-Layout, Version History |
Canvas Features
- Snap Grid — Nodes snap to a grid for clean alignment
- MiniMap — Bird’s-eye view of the full workflow (bottom-right corner)
- Zoom & Pan — Scroll to zoom, drag to pan, or use the controls
- Edge Labels — Automatic labels like “True”/“False”, “Approved”/“Rejected” on conditional edges
- Drop-on-Edge — Drop a node near an existing edge to automatically insert it into the flow
Building a Workflow
Add a Trigger Node
Every workflow starts with exactly one Trigger node. Drag it from the palette and configure the trigger type (incident event, webhook, cron schedule, or manual). See the Triggers guide for details.
Connect Action Nodes
Drag Action nodes onto the canvas and connect them to the trigger. Each action executes a task on a target system — SSH commands, HTTP requests, Kubernetes operations, Slack messages, etc. See the Actions guide.
Add Logic Nodes
Use Condition nodes to branch based on data, Delay nodes to pause execution, Approval nodes for human gates, and ForEach nodes to iterate over collections. See the Node Types guide.
Configure Each Node
Click any node to open its inspector on the right. Fill in the required fields — action type, connection, parameters, conditions, timeout, etc.
Every workflow must have exactly one Trigger node. The designer validates this before publishing and shows an error if no trigger is found.
Publishing & Versioning
Draft vs Published
| State | Description |
|---|---|
| Draft | Work in progress. Can be edited freely. Not active — won’t respond to events. |
| Published | Frozen snapshot of the workflow definition. Represents a specific version. |
| Active | A published workflow that is currently live and responding to events. |
Publishing a Workflow
Validate
Click Validate in the toolbar. The engine checks for:
- Exactly one trigger node
- All nodes have unique IDs
- All edges reference existing nodes
- No self-loops
- Required fields are filled
- No circular subworkflow references
Publish
Click Publish to create a versioned snapshot. The version number auto-increments (v1, v2, v3…). The published definition is immutable.
Version History
Every publish creates a numbered version. Access version history from the clock icon in the toolbar:- Timeline View — Chronological list of publishes with author and timestamp
- Version List — Table of all versions with publish date
- Diff Viewer — Side-by-side comparison showing added, removed, and modified nodes and edges
- Rollback — Restore the workflow definition to any previous published version
Rollback
Rollback replaces the current draft definition with the selected version’s definition. It does not auto-publish — you must publish again after rolling back.Workflow Templates
Start from pre-built templates to accelerate workflow creation:- Incident Response
- Infrastructure
- Notification
- DevOps
- Auto-Remediation — Restart service on critical incident, notify on Slack
- Escalation Notification — Multi-channel notification chain (Slack → SMS → Call)
- Incident Triage — Route incidents by severity and service to appropriate teams
Managing Workflows
Clone
Duplicate an existing workflow with Clone. The clone gets a new ID and name (suffixed with ”— Copy”), resets execution statistics, and starts in draft state.Activate / Deactivate
- Activate — Makes the workflow live. It will respond to configured triggers.
- Deactivate — Stops the workflow from responding to events. Running executions are not affected.
Auto-Disable
Workflows with cron triggers are automatically disabled after 5 consecutive execution failures. When auto-disabled:- A banner appears on the workflow showing the reason and disable timestamp
- The workflow stops receiving cron triggers
- You can re-enable it from the workflow settings after fixing the issue
Delete
Deleting a workflow is permanent. Running executions are cancelled, and the workflow is removed from all trigger evaluations.Workflow Statuses
| Status | Badge Color | Description |
|---|---|---|
| Draft | Gray | Work in progress, not published or activated |
| Active | Green | Published and responding to events |
| Inactive | Yellow | Published but not responding to events (deactivated) |
| Auto-Disabled | Red | Automatically disabled due to consecutive failures |
Best Practices
Start simple, add complexity gradually
Start simple, add complexity gradually
Begin with a trigger and one or two actions. Test the workflow end-to-end before adding conditions, error handlers, and parallel branches. It’s easier to debug a simple workflow than a complex one.
Use descriptive node names
Use descriptive node names
Rename nodes to describe their purpose: “Check if severity is critical” instead of “Condition 1”. This makes the workflow self-documenting and easier to debug.
Add error handlers for critical actions
Add error handlers for critical actions
If an SSH command or Kubernetes operation fails, you want to know immediately. Add Error Handler nodes to send a Slack notification or create a Jira ticket when critical actions fail.
Test with manual triggers first
Test with manual triggers first
Before activating event-based or cron triggers, test your workflow using the Execute button (manual trigger). This lets you verify the entire flow without waiting for real incidents.
Use version history before major changes
Use version history before major changes
Before making significant changes to an active workflow, note the current version number. If something goes wrong, you can rollback to the known-good version.
Keep workflows focused
Keep workflows focused
A workflow should do one thing well. Instead of a mega-workflow that handles everything, create separate workflows for different scenarios and use subworkflows to share common logic.
Troubleshooting
Validation fails with 'No trigger node found'
Validation fails with 'No trigger node found'
Every workflow must have exactly one Trigger node. Check that you’ve dragged a Trigger node onto the canvas and that it’s properly connected.
Workflow is active but not triggering
Workflow is active but not triggering
Steps:
- Verify the trigger type matches the events you expect (e.g.,
incident.createdvsincident.acknowledged) - Check trigger conditions — are they too restrictive? (e.g., filtering for severity=critical when your test incident is medium)
- For cron triggers, check if the workflow was auto-disabled
- For webhook triggers, verify the webhook key and secret
Can't publish workflow
Can't publish workflow
Click Validate to see specific errors. Common issues:
- Disconnected nodes (not reachable from the trigger)
- Missing required fields in action nodes (connection, action type)
- Self-referencing edges
- Circular subworkflow references
Workflow executes but actions fail
Workflow executes but actions fail
Check the execution detail page (Automation > Executions > [Execution]) for per-job error messages. Common causes:
- Connection credentials expired or not delivered
- Agent offline or unhealthy
- Template variables resolving to empty values
- Action timeout too short