Workflow Builder

Builder Overview

The StackFlow Workflow Builder is a visual no-code canvas for designing automation workflows. Workflows are composed of nodes connected by directed edges. The builder provides a palette of built-in node types plus custom script nodes for advanced logic. Workflows are stored as JSON in Aurora PostgreSQL and executed by the StackFlowAPI Lambda triggered via EventBridge or SQS.

⚙️ Minimum Requirements

DynamoDB: StackFlow_Workflow table with PK workflowId and steps JSON attribute
Feature Flag: workflow_builder enabled in StackFlow_FeatureFlag for the tenant
Role: Creating workflows requires itsm_manager, ai_engineer, or super_admin JWT claim
Lambda: StackFlowWorkflowEngine deployed and able to execute all step action types

Execution Engine: Workflows execute inside the StackFlowAPI Lambda function, which has access to all StackFlow APIs, AWS services (via IAM role), and the VPC network. Lambda's 300-second timeout applies to workflow execution. Long-running workflows should be broken into chained steps with SQS handoffs.

Node Types

Category	Node Type	Description
Triggers	ITSM Event	Triggered by record state changes
Triggers	Schedule	EventBridge cron expression
Triggers	SQS Message	Messages from StackFlow SQS queues
Triggers	Webhook	Inbound HTTP POST
Logic	Condition Branch	If/else based on variable values
Logic	Loop	Iterate over a list
Logic	Parallel	Run branches simultaneously
Actions	Update Record	Update any ITSM record field
Actions	Create Record	Create a new ITSM record
Actions	Send Notification	Email, SNS, webhook
Actions	AWS API Call	Call any AWS service API
AI	AI Classifier	LLM-based classification
AI	AI Text Generator	LLM-based text generation

Workflow Execution

Each workflow execution creates an execution record with a unique ID, start timestamp, current state, and variable snapshots at each step. Execution records are stored in Aurora for 90 days and visible in Workflows → Execution History. Failed executions are automatically retried (configurable per workflow, default 3 retries with exponential backoff) before being moved to the DLQ.

Variables and Data Mapping

Workflow variables are passed between nodes using a context object. Each node can read from and write to the context. Variable references use Jinja2-style double curly braces: {{incident.priority}}, {{ai_classifier.result.category}}. The context object is inspectable at each step in the execution trace.

{
  "node": "update_record",
  "config": {
    "record_type": "incident",
    "record_id": "{{trigger.incident_id}}",
    "updates": {
      "assignment_group": "{{ai_classifier.result.suggested_group}}",
      "work_notes": "Auto-assigned by AI workflow. Confidence: {{ai_classifier.result.confidence}}"
    }
  }
}

Version Control

Workflow definitions are versioned in Aurora. Each save creates a new version and the previous version is retained. Active workflows can be rolled back to any previous version from the workflow detail page. Workflow versions can also be exported as JSON for storage in version control systems like GitHub — use the GitHub Sync integration for automatic workflow-as-code management.

← Previous

SLA Alerts

Breach notification configuration

Auto-Remediation

SQS-driven automated fixes