Workflow Builder
Playbooks as directed graphs, not linear scripts
Response workflows in ManySignal are DAGs: action nodes connected by conditional edges. Execution forks on alert properties, entity attributes, and action results. Approval nodes pause execution until a named person responds. Every branch is visible before you run it.
How a workflow executes
Trigger
A workflow is triggered by a finding rule match, a manual analyst action, a case status change, or an external webhook. The trigger passes a structured context bundle — entity data, finding fields, case properties — to the first node.
Condition node
Conditional edges evaluate against context bundle fields. `finding.severity == 'critical' AND entity.is_privileged == true` routes to the isolation branch; everything else routes to the notification branch. Condition logic is displayed as readable text in the UI, not as code.
Action node
Action nodes execute a single governed action — suspend account, block IP, create JIRA ticket. The action runs at its configured autonomy level. If the autonomy level is approve-gated, execution pauses here and sends an approval notification.
Approval node
The named approver receives a notification with a summary of the proposed action, the entity context, and one-click approve/reject buttons. Approval actions via Slack or email are recorded in the case timeline.
Result branch
After an action completes, the result (success, failure, timeout) determines the next edge. A failed block-IP action can route to a manual-intervention node rather than continuing the playbook as if it succeeded.
Audit close
When a workflow completes, the full execution graph — which nodes ran, which were skipped, what each returned — is written to the case timeline as a structured record.
What the workflow builder handles
No-code node editor
Add nodes, connect edges, and configure conditions in a drag-and-drop canvas. Workflows can also be expressed as YAML for version control and CI review.
Dry-run mode
Run any workflow against a real or synthetic context bundle to see which nodes would execute, which would be blocked by guardrails, and what the rollback inventory would look like.
Conditional branching
Branch on any field in the context bundle: finding severity, entity criticality, blast radius, time of day, on-call rotation, previous action result. Branches can merge back or continue independently.
Loop and retry nodes
Poll for a condition (e.g., wait until an account is confirmed suspended) with a configurable interval and maximum retry count. Timeout routes to an escalation branch.
Parallel execution
Notify Slack AND create a JIRA ticket AND enrich with VirusTotal simultaneously. Fork nodes split execution across parallel branches; join nodes wait for all parallel branches to complete before continuing.
Sub-workflow reuse
Common action sequences — notify and await approval, enrich and score, isolate and snapshot — can be extracted as named sub-workflows and referenced by multiple parent workflows.
Workflow Builder — FAQ
Can I write workflows as code instead of using the visual editor?
Yes. Every workflow has a canonical YAML representation. You can edit YAML directly in the platform or check it into a git repository and deploy via the API. The visual editor and YAML stay in sync.
How do I handle a workflow that runs for hours waiting for a system to respond?
Wait nodes persist state between steps. A workflow waiting for an EDR isolation to confirm can pause for up to 24 hours, checking on a configurable interval, without consuming execution resources.
What is the maximum workflow complexity?
There is no enforced node limit. Practical limits come from approval latency and action rate limits on target systems. The platform warns if a workflow DAG has unreachable nodes or circular dependencies at save time.
Can a workflow read its own execution history?
Yes. A condition node can check how many times this workflow has run for a given entity in the last N days, what the result of the last run was, and which approver approved it — allowing escalation logic based on repeat behavior.
How does the workflow builder differ from a traditional SOAR playbook editor?
Traditional SOAR playbooks are the primary investigation logic — analysts start from scratch for each scenario. ManySignal workflows handle response execution after AI triage has already produced a verdict and evidence package. The workflow builder is simpler because investigation logic is handled by AI agents, not workflow nodes.
Can workflows be triggered by external events or only by ManySignal findings?
Workflows can be triggered by: ManySignal findings (primary), manual case actions, scheduled jobs (cron-style), and external webhooks. External triggers allow integration with monitoring tools, vulnerability scanners, and ticketing systems that can initiate ManySignal response workflows.
How are workflow templates maintained and updated?
Shipped workflow templates are maintained by ManySignal's response engineering team and updated when new integrations or best-practice patterns emerge. Template updates appear as a new version — existing deployments are not automatically updated, but you receive a notification to review and merge the changes.
Can we version-control workflows alongside detection rules?
Yes. Workflows export as YAML and can be committed to the same detection-as-code repository as detection rules. The CI pipeline validates workflow YAML syntax and action references. This gives you full GitOps governance over the entire detection-to-response pipeline.
What is the execution latency from finding creation to workflow start?
Workflow execution begins within 5 seconds of finding creation for autonomous tiers. Approve-gated workflows queue immediately and await the approval action. The approval can be taken from Slack or email without opening the platform, typically reducing approval latency to under 2 minutes for on-call analysts.
Build a playbook in under an hour
Shipped workflow templates cover the most common response patterns — customize them or start from scratch.