# Actions Examples

This page walks through common workflow patterns using the visual flow editor. Each example describes what the workflow does, what triggers it, and how to connect the blocks.

→ For step-by-step instructions on using the editor, see the [Actions User Guide](/actions/user-guide).

→ For building custom blocks, see the [Actions Developer Guide](/developer/actions-developer-guide).

---

## Email notification when a record is created

**What it does:** Sends an email to an admin when a new document (or any other record) is created.

**Setup:**
1. Add a **Document Created** trigger
2. Add a **Send Email** block — configure: recipient, subject, body template
3. Connect the trigger's output socket to the email block's input socket

**Variations:**
- Use **Text Replacer** blocks to include the created document's field values in the email body
- Add a **Conditional** block before the email block to only send when a specific field has a certain value (e.g., only notify for high-priority records)

---

## Multi-step data processing

**What it does:** Validates and transforms incoming data before saving it to a collection.

**Setup:**
1. Add a **Document Created** or **Webhook** trigger
2. Add a **Data Mapper** block — map fields from the trigger data to the target schema
3. Add a **Save Entity** block — configure the target collection
4. Connect: trigger → data mapper → save entity

**Error handling:**
- The **Save Entity** block has an `error` output socket — connect it to a **Log** block or a **Send Email** block to capture failures

→ See [Data Mapper Block](/developer/actions-blocks/data-mapper) for field mapping configuration.

---

## Conditional branching

**What it does:** Routes workflow execution down different paths based on a field value.

**Setup:**
1. Add a trigger (any type)
2. Add a **Conditional** block — configure the condition (e.g., `status === "approved"`)
3. Add two downstream blocks — one for the `true` path, one for the `false` path
4. Connect: trigger → conditional, then conditional's `true` socket → approval path, `false` socket → rejection path

**Example use cases:**
- Send a different email depending on whether an application is approved or rejected
- Save to different collections depending on a status field
- Skip processing for records that already have a certain field set

---

## External API integration

**What it does:** Calls an external REST API when a record changes — for example, posting data to a CRM or webhook receiver.

**Setup:**
1. Add a **Document Updated** trigger
2. Add a **Data Mapper** block — shape the trigger data into the format the external API expects
3. Add an **HTTP Request** block — configure: URL, method (POST/PUT), headers (e.g., Authorization), body from the data mapper output
4. Connect: trigger → data mapper → HTTP request

**Tips:**
- Store API keys in Application configuration rather than hardcoding them in the block
- Connect the HTTP Request block's `error` socket to a notification block to catch failed calls

---

## Scheduled workflows (cron triggers)

**What it does:** Runs a workflow on a recurring schedule — for example, a nightly data cleanup or a weekly report email.

**Common cron expressions:**

| Schedule | Expression |
|---|---|
| Every day at midnight | `0 0 * * *` |
| Every Monday at 8 AM | `0 8 * * 1` |
| Every hour | `0 * * * *` |
| Every 15 minutes | `*/15 * * * *` |
| First day of each month | `0 9 1 * *` |

**Setup:**
1. Add a **Cron** trigger — enter the cron expression
2. Add the blocks for the recurring task
3. Connect them

**Example — weekly summary email:**
1. Cron trigger: `0 9 * * 1` (Monday 9 AM)
2. **Fetch Entities** block — query the collection for records from the past week
3. **Data Mapper** block — format the results for the email
4. **Send Email** block — send the summary

---

## Customer onboarding workflow

**What it does:** When a new user registers, automatically creates a welcome task, sends a welcome email, and notifies the responsible team member.

**Setup:**
1. **User Registered** trigger
2. **Save Entity** block (A) — create a "Welcome call" task linked to the new user
3. **Send Email** block (B) — send a welcome email to the new user (use Text Replacer to personalize with their name)
4. **Send Email** block (C) — notify the account manager

Connect: trigger → A, trigger → B, trigger → C (all three blocks run in parallel from the same trigger output).

---

## Document approval workflow with escalation

**What it does:** When a document is submitted for review, notify the approver. If not approved within a set time, escalate.

**Setup (basic approval notification):**
1. **Document Updated** trigger — filter on `status` changing to `"pending_review"`
2. **Send Email** block — notify the approver with a link to review

**Adding escalation (requires cron + data lookup):**
1. **Cron** trigger — runs every few hours
2. **Fetch Entities** block — queries for documents with `status = "pending_review"` and `submittedAt` older than 48 hours
3. **Conditional** block — checks if results are non-empty
4. **Send Email** block — escalation notice to the approver's manager

---

## Tips for building workflows

**Start simple.** Build and test the happy path first — a single trigger connected to a single output block. Add error handling and branching once the core flow works.

**Use meaningful block labels.** In the flow editor, rename blocks to describe what they do (e.g., "Notify admin" instead of "Send Email"). This makes complex workflows readable.

**Connect error sockets.** Every block that can fail (HTTP requests, save operations) has an `error` output socket. Always connect it to at least a **Log** block so failures are visible.

**Test with real data.** Trigger your workflow manually with a known test record to verify the data mapping and conditions are working as expected before enabling it in production.