Workflow Design

Good workflow design makes automations easier to build, maintain, and debug. This guide covers architecture patterns, design principles, and common approaches for building effective workflows.

Design Principles

1. Start with the End Goal

Before building, clearly define:

• What triggers the workflow? (meeting ends, schedule, manual)
• What should happen? (send message, update CRM, create task)
• What data is needed? (meeting details, AI analysis, context)

Work backwards from the desired outcome to determine required steps.

2. Keep Workflows Focused

Each workflow should do one logical thing:

✅ Good: "Post-meeting summary to Slack" ✅ Good: "Create follow-up tasks from meeting" ✅ Good: "Update CRM after deal meetings"

❌ Bad: "Do everything after meeting ends" (too broad)

3. Prefer Simplicity

The simplest workflow that achieves your goal is usually the best:

• Fewer nodes = easier to understand
• Linear flows = easier to debug
• Explicit logic = easier to maintain

4. Plan for Failure

Every workflow should handle errors gracefully:

• Connect error outputs
• Consider what happens if data is missing
• Plan for API failures

Architecture Patterns

Pattern: Linear Pipeline

The simplest pattern—data flows through sequential steps:

[Trigger] → [Load] → [Process] → [Action]

Use when:

• Steps are dependent on each other
• Each step needs the previous step's output
• Simple, sequential logic

Example: Meeting summary to Slack

[Meeting Ended] → [Load Meeting] → [AI: Summarize] → [Slack Post]

Pattern: Parallel Processing

Run multiple operations concurrently, then combine:

               ┌─→ [Operation A] ─┐
[Load Data] ───┤                  ├──→ [Combine] → [Action]
               └─→ [Operation B] ─┘

Use when:

• Operations are independent
• You need multiple types of analysis
• Speed matters (parallel is faster than sequential)

Example: Multi-faceted meeting analysis

                 ┌─→ [AI: Summary] ──────┐
[Load Meeting] ──┤                       ├──→ [Zip] → [Send Report]
                 └─→ [AI: Action Items] ─┘

Pattern: Conditional Branching

Route to different paths based on conditions:

[Process]
    ↓
[If: condition]
    ├─ True ──→ [Path A]
    └─ False ─→ [Path B]

Use when:

• Different actions for different scenarios
• Filtering out unwanted cases
• Priority-based routing

Example: Priority-based notification

[AI: Classify urgency]
         ↓
    [If: urgent?]
    ├─ True ──→ [SMS + Slack]
    └─ False ─→ [Email only]

Pattern: Fan-Out Processing

Process each item in a collection individually:

       [Load Data]
            ↓
   [Select Many: items]
            ↓
    ┌───────┼───────┐
    ↓       ↓       ↓
 Item 1  Item 2  Item 3
    ↓       ↓       ↓
[Process][Process][Process]

Use when:

• Need to act on each item separately
• Sending individual notifications
• Creating separate records

Example: Email each attendee

[Load Meeting] → [Select Many: attendees] → [Email Send]

Pattern: Context Enrichment

Add shared context to items being processed:

[Load Context] ──────────┐
                         ├──→ [Broadcast] → [Process with context]
[Load Items] → [Expand] ─┘

Use when:

• Items need access to shared data
• Personalizing per-item with common context
• Combining different data sources

Example: Personalized emails with meeting context

                  ┌─→ (meeting context) ────────┐
[Load Meeting] ───┤                             ├──→ [Broadcast] → [Email]
                  └─→ [Select Many: attendees] ─┘

Pattern: Multi-Stage Sequence

Chain of actions with delays:

[Trigger] → [Action 1] → [Wait] → [Action 2] → [Wait] → [Action 3]

Use when:

• Nurture sequences
• Spaced follow-ups
• Reminder chains

Example: Follow-up sequence

[Meeting Ended] → [Same-day thanks] → [Wait 3 days] → [Check-in email]

Naming Conventions

Workflow Names

Use clear, descriptive names:

Include:

• What it does
• Where output goes (optionally)
• Trigger context (optionally)

Node Names

Rename nodes to describe their specific purpose:

Workflow Organization

Logical Grouping

Group related workflows by function:

• Meeting Workflows: Post-meeting actions
• Notification Workflows: Alerts and communications
• CRM Workflows: Data synchronization
• Report Workflows: Scheduled summaries

Version Management

When changing workflows:

1. Make edits in draft mode
2. Test thoroughly before releasing
3. Release creates new version
4. Old version becomes Superseded automatically

Documentation

For complex workflows, document:

• Purpose and trigger conditions
• Expected inputs and outputs
• Business logic and rules
• Error handling approach

Common Design Mistakes

Mistake: Doing Too Much

❌ Problem: Single workflow tries to handle every meeting scenario

✅ Solution: Create separate workflows for distinct use cases

Mistake: Ignoring Errors

❌ Problem: Error outputs left disconnected

✅ Solution: Always handle errors, even with just logging + Sink

Mistake: No Testing Path

❌ Problem: Can only test by waiting for real events

✅ Solution: Use MANUAL trigger during development

Mistake: Hardcoded Values

❌ Problem: Values like channel IDs embedded in templates

✅ Solution: Use variables, expressions, and configuration

Mistake: Over-Complication

❌ Problem: Complex conditional logic that's hard to follow

✅ Solution: Simplify or split into multiple workflows

Workflow Checklist

Before releasing, verify:

• Trigger appropriate: Right event, right conditions
• Data flows correctly: All nodes get required inputs
• Errors handled: All error outputs connected
• Branches terminated: All paths end at action or Sink
• Tested: Works with real data via MANUAL trigger
• Naming clear: Workflow and nodes have descriptive names
• Purpose documented: Clear what the workflow does

Example: Complete Workflow Design

Goal: Automatically summarize meetings and send to Slack, with different handling for urgent vs. regular meetings.

Design:

[Event Trigger: MEETING_ENDED]
              ↓
        [Load Meeting]
         ↓         ↓
      Success    Error → [Log error] → [Sink]
         ↓
    ┌────┴────────────────────┐
    ↓                         ↓
(meeting data)    [AI: Analyze & Classify]
    ↓                         ↓
    └──────────┬──────────────┘
               ↓
         [Zip: combine]
               ↓
         [If: urgent?]
         ↓           ↓
        Yes          No
         ↓           ↓
[Slack: #urgent] [Slack: #recaps]

Key design decisions:

1. Load Meeting immediately after trigger
2. Error handling for load failures
3. AI analysis includes urgency classification
4. Zip combines original data with analysis
5. Conditional routing based on urgency
6. Different Slack channels for different priorities