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:

| Operation | WRONG (generic) | RIGHT (native) | |-----------|-----------------|-----------------| | Create case | core.transform.reshape + manual POST | core.cases.create_case | | Update case | core.transform.reshape + manual POST | core.cases.update_case | | Add comment | core.http_request to /cases/comments | core.cases.create_comment | | VirusTotal lookup | core.http_request with manual headers | tools.virustotal.* | | CrowdStrike query | core.http_request with OAuth flow | tools.crowdstrike.* | | Splunk search | core.http_request to Splunk API | tools.splunk.* | | Defender alerts | core.http_request with Azure auth | tools.microsoft_defender.* | | SharePoint files | core.http_request with Graph API | tools.sharepoint.* | | Okta user mgmt | core.http_request to Okta API | tools.okta.* |

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

| Element | Width | Height | Notes | |---------|-------|--------|-------| | Trigger node | ~280px | ~200px | Taller than actions | | Action node | ~250px | ~100px | Standard UDF node | | Viewport default | - | - | Best centered at x=500 |

Spacing Rules

| Rule | Value | Why | |------|-------|-----| | Trigger position | (500, 0) — always | Top-center anchor point | | First action Y | y >= 300 | Trigger is ~200px tall, leave 100px margin | | Vertical gap | 200px between levels | Nodes ~100px tall, 200px gives breathing room | | Horizontal gap | 350px minimum between parallel siblings | Nodes ~250px wide, avoids overlap | | Main spine X | x = 500 | Center of viewport, aligns with trigger |

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

| Anti-pattern | Problem | Fix | |-------------|---------|-----| | All nodes at (0, 0) | Everything overlaps, invisible graph | Always call move_nodes after creation | | Trigger not at (500, 0) | Trigger misaligned with actions | Always call update_trigger_position | | Parallel nodes too close | Overlap when = 300 | | Inconsistent X for linear chain | Zigzag layout, hard to read | Same X for all linear nodes |

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](./COMMON_MISTAKES.md)
• [Examples](./examples.md)
• [README](./README.md)

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: adrojis
• Source: adrojis/tracecat-skills
• License: MIT

Install and usage instructions live in the source repository linked above.