Core Concepts

Understanding these core concepts will help you design and build effective workflows. This page covers the fundamental building blocks of Agents.

Workflows

A workflow is a container for your automation logic. It defines what triggers the automation, what processing happens, and what actions are taken.

Workflow Properties

Workflow Lifecycle

Draft → Release → Active → (New Release) → Superseded

1. Draft: Workflow is being edited and won't execute
2. Active: Workflow is live and will execute when triggered
3. Superseded: Old version replaced by a newer release

Nodes

Nodes are the building blocks of workflows. Each node performs a specific function: triggering, processing data, calling AI, or taking actions.

Node Categories

Node Structure

Every node has:

┌───────────────────────────────────┐
│            Node Name              │
├───────────────────────────────────┤
│  ○ Input Port 1                   │
│  ○ Input Port 2 (if applicable)   │
├───────────────────────────────────┤
│        Configuration              │
│        Parameters                 │
├───────────────────────────────────┤
│  ● Success Output                 │
│  ● Error Output (if applicable)   │
└───────────────────────────────────┘

• Input Ports: Receive data from upstream nodes
• Configuration: Parameters that control the node's behavior
• Output Ports: Send data to downstream nodes (success and/or error channels)

Execution Modes

Nodes operate in one of two modes:

Edges (Connections)

Edges connect nodes together, defining how data flows through your workflow. An edge connects an output port of one node to an input port of another.

[Trigger] ─success─→ [AI Prompt] ─success─→ [Slack Post]
                          │
                          └─error─→ [Error Handler]

Connection Rules

• Every input port must receive exactly one connection
• Output ports can connect to multiple downstream nodes
• Connections determine data flow and execution order
• Error channels allow branching on failure

Triggers

Triggers are special nodes that start workflow execution. A workflow has exactly one trigger.

Trigger Types

Event Types

Event triggers can listen for:

Executions

An execution is a single run of a workflow. When a trigger fires, a new execution is created.

Execution Lifecycle

             ┌→ Completed
Queued → Running ─┼→ Failed
             └→ Canceled

Execution Tracking

Each execution records:

• Start and end times
• Status of each node
• Input and output data at each step
• Error details if failures occur

Data Flow

Data flows through workflows via connections between nodes. Understanding how data moves is key to building effective workflows.

The trigger Object

When a workflow starts, the trigger node outputs a trigger object containing event data:

{
  "meetingPlanId": "abc123",
  "dealRoomId": "xyz789",
  "organizationId": "org456",
  "event": "MEETING_ENDED",
  "firedAt": "2024-01-15T10:30:00Z"
}

The json Variable

Within node configurations, you can reference upstream data using the json variable:

{{ json.meeting.title }}
{{ json.callRecording.transcriptSummary }}

Data Transformation

Data transforms as it flows through nodes:

    Trigger (event data)
            ↓
Load Meeting (adds meeting details)
            ↓
  AI Prompt (adds AI analysis)
            ↓
Slack Post (consumes data, produces confirmation)

Expressions (CEL)

CEL (Common Expression Language) is used for dynamic values and conditions in node configurations.

Common Uses

Examples

// Access trigger data
trigger.dealRoomId

// Access upstream node output
json.meeting.title

// Conditional expression
json.sentiment == "positive" ? "Great meeting!" : "Follow up needed"

// Check if field exists
has(json.callRecording)

Templates (Liquid)

Liquid is a templating language used for generating text content in message nodes.

Syntax

Hello {{ json.attendee.name }},

Thank you for meeting with us on {{ json.meeting.startTime | date: "%B %d" }}.

{% if json.actionItems.size > 0 %}
Here are the action items we discussed:
{% for item in json.actionItems %}
- {{ item }}
{% endfor %}
{% endif %}

Best regards,
{{ author.name }}

Available Objects

Retry Policies

Nodes can fail due to temporary issues (network problems, rate limits). Agents automatically retries failed nodes using configurable policies.

Retry Strategies

Default Configuration

Max Attempts: 3
Initial Backoff: 1 second
Max Backoff: 30 seconds
Strategy: exponential_jitter

Dead Letter Queue (DLQ)

When a node exhausts all retries, the failure is recorded in the Dead Letter Queue. This prevents data loss and allows for manual review and retry.

DLQ Workflow

Node Fails → Retry 1 → Retry 2 → Retry 3 → DLQ
                                            ↓
                                      Manual Review
                                            ↓
                                  Fix & Retry OR Discard

Key Terminology Summary

Next Steps

Now that you understand the concepts, set up your account:

→ Continue to Setup