Loaders

Loader nodes fetch data from external sources and make it available to downstream nodes in your workflow. They bridge the gap between trigger context and the detailed data you need for processing.

Available Loaders

Why Use Loaders?

Triggers provide minimal context—just IDs and event information. Loaders fetch the full data you need:

Trigger Output                    After Load Meeting
──────────────                    ─────────────────
{                                 {
  meetingPlanId: "mp_123",   →      meeting: {
  event: "MEETING_ENDED"              title: "Q1 Review",
}                                     startTime: "...",
                                      attendees: [...],
                                    },
                                    callRecording: {
                                      transcript: "...",
                                      keyStatements: [...]
                                    }
                                  }

Loader Characteristics

Data Enrichment

Loaders add rich context to your workflow data, enabling:

• AI analysis of meeting content
• Personalized messages with attendee names
• CRM updates with meeting details

Error Handling

Loaders have error outputs for cases where data cannot be fetched:

• Meeting not found
• Transcript not yet available
• Permission issues

Caching

Loader data is fetched fresh for each execution. There's no caching between executions, ensuring you always have current data.

Common Patterns

Pattern: Trigger → Load → Process

The most common pattern uses a loader immediately after the trigger:

[Event Trigger]
      │
      ▼
[Load Meeting] ◄── Fetches full meeting data
      │
      ▼
[AI Prompt] ────── Now has transcript to analyze
      │
      ▼
[Slack Post] ───── Can include attendee names, meeting title

Pattern: Conditional Loading

Only load data when needed:

[Event Trigger]
      │
      ▼
[If: needs detailed data?]
    ├── Yes ──▶ [Load Meeting] ──▶ [Full Processing]
    └── No ───▶ [Simple Action] ── Quick path

Pattern: Error Handling for Missing Data

Handle cases where meeting data isn't available:

[Load Meeting]
    ├── Success ──▶ [Process with Data]
    └── Error ────▶ [Log Error] ──▶ [Sink]

Best Practices

1. Load Early

Place loaders near the beginning of your workflow before nodes that need the data.

2. Handle Errors

Always connect error outputs to appropriate handling:

• Logging for debugging
• Alerts for critical workflows
• Graceful termination with Sink

3. Don't Over-Load

Only use loaders when you need the data. If you just need the meeting ID from the trigger, skip the loader.

4. Consider Timing

Some data may not be available immediately:

• Transcripts take time to process after meetings end
• Consider using MEETING_END + small delay for transcript-dependent workflows

Future Loaders

Additional loader nodes may be added to support:

• Loading deal room details
• Loading contact information
• Loading historical meetings
• Loading CRM records

Next Steps

• Load Meeting - Detailed documentation