Tracecat Workflow Patterns

Tracecat Workflow Patterns

You are an expert at designing SOAR workflow patterns for Tracecat. Use these patterns as templates when building security automation workflows.

Critical Rule: Always Prioritize Native Action Types

When building any workflow, ALWAYS check for and use native/official action types BEFORE falling back to generic actions:

Fallback rules:

• core.http_request → ONLY when no native integration exists for that API
• core.transform.reshape → ONLY for data transformation/aggregation, never for CRUD operations
• core.script.run_python → ONLY when logic cannot be expressed with native actions or expressions

Pattern 1: Alert Triage

Use case: Automatically triage incoming security alerts.

Webhook trigger → Enrich alert (VirusTotal, AbuseIPDB) → Score risk → Decision:
  - High risk → Create case + Notify SOC (Slack)
  - Medium risk → Create case
  - Low risk → Log and close

Key actions: tools.virustotal.analyze_url, tools.abuseipdb.check_ip, core.transform.reshape

Pattern 2: Incident Response

Use case: Automated incident response playbook.

Case created → Gather context (SIEM query) → Containment:
  - Block IP (firewall)
  - Disable user (IAM)
  - Isolate host (EDR)
→ Document actions → Notify stakeholders

Key actions: tools.crowdstrike.contain_host, core.http.request

Pattern 3: Scheduled Scan

Use case: Periodic security scanning and reporting.

Cron trigger (daily) → Scan targets → Compare with baseline:
  - New findings → Create cases
  - Resolved findings → Close cases
→ Generate report → Email/Slack

Key actions: core.workflow.execute (sub-workflow), tools.slack.post_message

Pattern 4: Data Enrichment Pipeline

Use case: Enrich IOCs from multiple sources.

Input IOC → Parallel lookup:
  - VirusTotal
  - Shodan
  - GreyNoise
  - AbuseIPDB
→ Merge results → Score → Store in table

Key actions: Use parallel execution with core.transform.reshape to merge

Pattern 5: Notification Pipeline

Use case: Smart notification routing based on severity.

Trigger → Evaluate severity:
  - Critical → PagerDuty + Slack #critical + Email
  - High → Slack #alerts + Email
  - Medium → Slack #alerts
  - Low → Log only

Key actions: tools.slack.post_message, core.http.request (PagerDuty API)

Design Principles

1. Idempotency — Workflows should be safe to re-run
2. Error handling — Always add fallback paths for action failures
3. Deduplication — Check if a case/alert already exists before creating
4. Audit trail — Log key decisions with case comments
5. Modularity — Break complex workflows into sub-workflows
6. Node layout — Always position nodes after creation (see below)

Node Layout Guidelines

When building workflows programmatically, always reposition nodes. MCP-created nodes default to (0,0) and overlap.

Dimensions and Constants

Spacing Rules

Layout Patterns with Exact Coordinates

Linear chain (most common):

Trigger:    (500, 0)
Action 1:   (500, 300)     ← first action at y=300
Action 2:   (500, 500)     ← +200
Action 3:   (500, 700)     ← +200
Action 4:   (500, 900)     ← +200

Fan-out / fan-in (2 parallel branches):

Trigger:       (500, 0)
Parent:        (500, 300)
                 ┌──┴──┐
Left branch:  (200, 500)    Right branch: (800, 500)
                 └──┬──┘
Merge:         (500, 700)
Next:          (500, 900)

• Siblings offset ±300 from center (200 and 800 = 600px apart > 350px minimum)
• Merge node centered below at same x as parent

Fan-out / fan-in (3 parallel branches):

Trigger:          (500, 0)
Parent:           (500, 300)
              ┌─────┼─────┐
Left:       (150, 500)  Center: (500, 500)  Right: (850, 500)
              └─────┼─────┘
Merge:            (500, 700)

• 350px between each sibling (150 → 500 → 850)

Decision / conditional branches (success + error):

Trigger:       (500, 0)
Action:        (500, 300)
         ─success─┘ └─error─
Success path: (300, 500)    Error path: (700, 500)
              └──────┬──────┘
Final:         (500, 700)    ← join_strategy: any

Diamond pattern (split then merge):

Trigger:       (500, 0)
Fetch data:    (500, 300)
           ┌────┴────┐
Enrich A: (200, 500) Enrich B: (800, 500)
           └────┬────┘
Score:     (500, 700)   ← depends on both, join_strategy: all
Decision:  (500, 900)

Positioning Anti-Patterns

MCP Tool Calls

Always execute these 3 calls after creating actions:

1. tracecat_add_edges(...)               # Connect all nodes
2. tracecat_move_nodes(...)              # Position action nodes
3. tracecat_update_trigger_position(...) # Position trigger at (500, 0)

Format for move_nodes: {"positions": [{"action_id": "uuid", "x": 500, "y": 300}, ...]}

See tracecat-mcp-tools-expert skill for full Graph API details.

Related Skills

• tracecat-mcp-tools-expert — MCP tool reference and Graph API operations
• tracecat-yaml-syntax — YAML syntax for workflow definitions
• tracecat-integration-expert — Configure external tool integrations
• tracecat-case-management — Case lifecycle patterns
• tracecat-validation-debug — Debug and validate workflows
• tracecat-code-python — Python scripting for data processing actions

Reference Files

• Common Mistakes
• Examples
• README