Title: Actions Examples Description: Practical examples and common workflow patterns for the Actions system Tags: actions, examples, workflows --- 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. → For building custom blocks, see the 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: Add a Document Created trigger Add a Send Email block — configure: recipient, subject, body template 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: Add a Document Created or Webhook trigger Add a Data Mapper block — map fields from the trigger data to the target schema Add a Save Entity block — configure the target collection 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 for field mapping configuration. Conditional branching What it does: Routes workflow execution down different paths based on a field value. Setup: Add a trigger (any type) Add a Conditional block — configure the condition (e.g., status === "approved") Add two downstream blocks — one for the true path, one for the false path 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: Add a Document Updated trigger Add a Data Mapper block — shape the trigger data into the format the external API expects Add an HTTP Request block — configure: URL, method (POST/PUT), headers (e.g., Authorization), body from the data mapper output 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: Add a Cron trigger — enter the cron expression Add the blocks for the recurring task Connect them Example — weekly summary email: Cron trigger: 0 9 1 (Monday 9 AM) Fetch Entities block — query the collection for records from the past week Data Mapper block — format the results for the email 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: User Registered trigger Save Entity block (A) — create a "Welcome call" task linked to the new user Send Email block (B) — send a welcome email to the new user (use Text Replacer to personalize with their name) 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): Document Updated trigger — filter on status changing to "pending_review" Send Email block — notify the approver with a link to review Adding escalation (requires cron + data lookup): Cron trigger — runs every few hours Fetch Entities block — queries for documents with status = "pending_review" and submittedAt older than 48 hours Conditional block — checks if results are non-empty 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.