Skip to main content

Workflow Examples

These six examples show real-world automations you can build in Automation Hub. Each one walks through the business problem, the workflow steps, and what you need to get started. Use them as blueprints for your own workflows.

Example 1: Daily Sales Report​

The problem: Your finance team needs a daily summary of sales numbers, delivered to their inbox and posted to Slack every morning before the workday starts.

Flow diagram​

Schedule Trigger
SQL Database
Format
Email
Slack

Runs automatically every morning — no manual work needed.

Step breakdown​

StepNode TypeActionWhat it does
1Schedule TriggerCron expressionFires every day at 8:00 AM
2SQL DatabaseExecute QueryRuns a query to pull yesterday's sales totals grouped by region
3FormatCreate MessageBuilds a readable summary with totals, top products, and comparisons
4EmailSend EmailSends the formatted report to the finance distribution list
5SlackPost MessagePosts a shorter summary to the #sales channel

What you'll need​

  • Connections: SQL Database (your sales database), Email (SMTP server), Slack (workspace token)
  • Global Variables: FINANCE_EMAIL_LIST (recipient addresses), SALES_DB_NAME (database name)

Key configuration highlights​

  • Schedule Trigger: Set the cron expression to 0 8 * * * for 8 AM daily. Adjust the timezone to match your team's location.
  • SQL Database: Use a query like SELECT region, SUM(amount) as total FROM sales WHERE sale_date = CURDATE() - INTERVAL 1 DAY GROUP BY region. Make sure your database connection has read-only access.
  • Format: Reference the query results using the previous step's output variables. Build both a detailed version (for email) and a short version (for Slack).
  • Email: Set the "To" field to your global variable FINANCE_EMAIL_LIST. Use a clear subject line like "Daily Sales Report — [date]".
  • Slack: Target the #sales channel. Include a link to the full report if your company uses a dashboard.

What the output looks like​

The finance team receives an email at 8 AM with a table showing sales by region, top-selling products, and a comparison to the previous day. The Slack message is a condensed version with headline numbers and a quick trend indicator (up or down from yesterday).

Example 2: New Customer Onboarding​

The problem: When a new customer signs up through your website or CRM, you need to validate their information, create a database record, send a welcome email, and notify the sales team — all without anyone lifting a finger.

Flow diagram​

Webhook Trigger
Conditional
SQL Database
Email
Slack

Fires instantly when a new customer signs up.

Step breakdown​

StepNode TypeActionWhat it does
1Webhook TriggerReceive POSTListens for new signups from your CRM or website form
2ConditionalCheck email validityVerifies the customer email matches a valid format and is not a disposable address
3SQL DatabaseInsert RecordCreates a new customer row in the customers table
4EmailSend EmailSends a personalized welcome email to the new customer
5SlackPost MessageNotifies the sales team in #new-customers with the customer's name and plan

What you'll need​

  • Connections: SQL Database (customer database), Email (SMTP server), Slack (workspace token)
  • Global Variables: WELCOME_EMAIL_TEMPLATE (template name or ID), SALES_SLACK_CHANNEL (channel name)

Key configuration highlights​

  • Webhook Trigger: Configure your CRM or website form to POST to the webhook URL that Automation Hub provides. The payload should include name, email, company, and plan fields.
  • Conditional: Set the condition to validate the email format. If the email is invalid, the workflow stops and logs the issue — no garbage data gets into your database.
  • SQL Database: Use an INSERT statement with parameterized values from the webhook payload. Example: INSERT INTO customers (name, email, company, plan, created_at) VALUES (?, ?, ?, ?, NOW()).
  • Email: Use your welcome email template. Personalize it with the customer's name and plan details pulled from the webhook payload.
  • Slack: Format the message to include the customer name, company, and plan so the sales team has context at a glance.

What the output looks like​

Within seconds of a signup, the customer gets a welcome email, the database has their record, and the sales team sees a Slack notification like: "New customer: Jane Smith from Acme Corp signed up for the Pro plan."

Example 3: File Transfer Pipeline​

The problem: Every night, a vendor uploads CSV files to their SFTP server. You need to download those files, convert them to a usable format, load the data into your database, and confirm everything went smoothly — or alert someone if it didn't.

Flow diagram​

Schedule Trigger
SFTP Download
Parse CSV
SQL Database
Email

Nightly file transfer with built-in error handling.

Step breakdown​

StepNode TypeActionWhat it does
1Schedule TriggerCron expressionFires every night at 2:00 AM when system load is low
2SFTPDownload FilesConnects to the vendor's SFTP server and downloads new CSV files
3ParseCSV to JSONConverts each CSV file into structured JSON records
4SQL DatabaseBatch InsertInserts the parsed records into the staging table
5EmailSend SummarySends a completion report with file counts and row counts
6Email (error branch)Send AlertIf any step fails, sends a failure alert to the data engineering team

What you'll need​

  • Connections: SFTP (vendor server credentials), SQL Database (your data warehouse), Email (SMTP server)
  • Global Variables: SFTP_REMOTE_PATH (directory on vendor server), DATA_TEAM_EMAIL (alert recipients), STAGING_TABLE (target table name)

Key configuration highlights​

  • Schedule Trigger: Set the cron to 0 2 * * * for 2 AM nightly. Choose a time when your database has low traffic.
  • SFTP: Point to the vendor's server using the SFTP connection. Set the remote directory to your global variable SFTP_REMOTE_PATH. Optionally filter by file extension (.csv only) and move processed files to an archive folder.
  • Parse: Select CSV as the input format and JSON as the output. Configure delimiter, header row, and encoding if the vendor uses non-standard settings.
  • SQL Database: Use a batch insert for performance. Map each JSON field to the corresponding database column. Consider using a staging table first, then running a merge/upsert to production.
  • Error handling: Add an error branch on the workflow. If any step fails, the error branch sends an email to DATA_TEAM_EMAIL with the step name, error message, and timestamp so the team can investigate quickly.

What the output looks like​

On success, the data engineering team gets a morning email: "Nightly file transfer complete — 3 files downloaded, 12,450 records inserted." On failure, they get an immediate alert with the specific error so they can fix it before business hours.

Example 4: Multi-Step Approval Workflow​

The problem: Expense requests under $5,000 can be auto-approved, but anything above that needs a manager's sign-off before the payment goes through. You want the whole process handled automatically, with email confirmations at every stage.

Flow diagram​

Manual Trigger
Conditional
HIL Approval
REST API
Email

Smart routing with human-in-the-loop approval for high-value requests.

Step breakdown​

StepNode TypeActionWhat it does
1Manual TriggerAccept input parametersCollects amount, description, requester_email, and cost_center
2ConditionalCheck amount thresholdEvaluates whether amount > 5000
3aHIL (Human-in-the-Loop)Request approvalIf over $5,000: pauses the workflow and sends an approval request to the manager
3bREST APIAuto-approveIf $5,000 or under: skips approval and goes straight to payment
4REST APISubmit paymentCalls the payment system API to process the approved expense
5aEmailSend confirmationOn approval: sends a confirmation email to the requester
5bEmailSend rejection noticeOn rejection: sends a rejection email with the manager's reason

What you'll need​

  • Connections: REST API (payment system endpoint), Email (SMTP server)
  • Global Variables: PAYMENT_API_URL (payment system base URL), APPROVAL_THRESHOLD (dollar amount, default 5000), MANAGER_EMAIL (approver's email address)

Key configuration highlights​

  • Manual Trigger: Define input parameters: amount (number), description (text), requester_email (email), and cost_center (text). These values are entered by the person starting the workflow.
  • Conditional: Set the condition to compare amount against your APPROVAL_THRESHOLD global variable. This makes it easy to adjust the threshold later without editing the workflow.
  • HIL (Human-in-the-Loop): Configure the approval step to notify the manager via email. Include the amount, description, and requester name in the approval request. The manager clicks "Approve" or "Reject" and can add a comment.
  • REST API: On approval (or auto-approval), make a POST request to your payment system with the expense details. Include authentication headers from your REST API connection.
  • Email (confirmation): Send to the requester with the approved amount, payment reference number (from the API response), and expected processing time.
  • Email (rejection): Send to the requester with the rejection reason from the manager's comment.

What the output looks like​

For a $3,000 expense: it's auto-approved instantly, the payment API is called, and the requester gets a confirmation email within seconds. For a $7,500 expense: the manager gets an approval email, reviews it, clicks "Approve," and the payment processes automatically. The requester is notified at every stage.

Example 5: Data Sync Between Systems​

The problem: Two systems need to stay in sync. System A is the source of truth, and any records updated in the last hour need to be pushed to System B. This needs to happen every hour, all day, without manual intervention.

Flow diagram​

Schedule Trigger
REST API (Fetch)
Loop
REST API (Push)
Slack

Hourly sync with record-level processing and smart change detection.

Step breakdown​

StepNode TypeActionWhat it does
1Schedule TriggerCron expressionFires every hour on the hour
2REST APIGET requestFetches all records from System A that were updated in the last hour
3LoopIterate over recordsProcesses each updated record one at a time
4Conditional (inside loop)Check record statusDetermines if the record is new, updated, or deleted
5REST API (inside loop)POST/PUT/DELETECreates, updates, or removes the corresponding record in System B
6SlackPost summaryAfter the loop completes, posts a sync summary to #integrations

What you'll need​

  • Connections: REST API for System A, REST API for System B, Slack (workspace token)
  • Global Variables: SYSTEM_A_BASE_URL, SYSTEM_B_BASE_URL, SYNC_LOOKBACK_MINUTES (default 60), INTEGRATIONS_CHANNEL (Slack channel)

Key configuration highlights​

  • Schedule Trigger: Set the cron to 0 * * * * for every hour on the hour. If your systems have heavy traffic during business hours, consider running more frequently (every 30 minutes) during peak times.
  • REST API (fetch): Call System A's API with a filter for records modified since the last sync. Use a query parameter like ?updated_after=<timestamp>. Calculate the timestamp using the SYNC_LOOKBACK_MINUTES variable.
  • Loop: Set the loop to iterate over the array of records returned by the fetch step. Each iteration processes one record.
  • Conditional (inside loop): Check the record's status or action field. Route to the correct API method: POST for new records, PUT for updates, DELETE for removals.
  • REST API (push): Call System B's API with the appropriate HTTP method based on the conditional result. Map the fields from System A's format to System B's expected format.
  • Slack: After the loop finishes, post a summary: "Hourly sync complete — 15 records created, 8 updated, 2 deleted." Include the total count and any errors.

What the output looks like​

Every hour, the workflow quietly syncs changes. The #integrations Slack channel gets a brief update: "System A → B sync complete: 25 records processed (15 new, 8 updated, 2 deleted). 0 errors." If any records fail, they're listed individually so someone can investigate.

Example 6: Server Health Monitoring​

The problem: Your operations team needs to know immediately when a production server has issues. Instead of waiting for users to report problems, you want proactive monitoring that checks server health every 15 minutes and alerts the right people.

Flow diagram​

Schedule Trigger
SSH
Conditional
Slack Alert
Email Alert

Proactive monitoring with instant alerts when something goes wrong.

Step breakdown​

StepNode TypeActionWhat it does
1Schedule TriggerCron expressionFires every 15 minutes around the clock
2SSHRun commandConnects to the server and runs a health check script
3ConditionalCheck outputLooks for error keywords in the command output (e.g., "ERROR", "CRITICAL", "disk full")
4aSlack (error branch)Post alertIf errors found: sends an urgent alert to the #ops channel
4bLog (healthy branch)Record resultIf healthy: logs the result for audit purposes, no notification sent
5Email (error branch)Send alertSends a detailed alert email to the on-call team with the full error output

What you'll need​

  • Connections: SSH (production server credentials), Slack (workspace token), Email (SMTP server)
  • Global Variables: SERVER_HOST (server address), HEALTH_CHECK_SCRIPT (path to the script on the server), OPS_CHANNEL (Slack channel), ONCALL_EMAIL (on-call team email)

Key configuration highlights​

  • Schedule Trigger: Set the cron to */15 * * * * for every 15 minutes. For critical production servers, you might want to go as frequent as every 5 minutes.
  • SSH: Connect using your SSH connection (key-based authentication recommended). Run the health check script: a command like /opt/scripts/healthcheck.sh that checks disk space, memory usage, CPU load, and critical service status. The script should output a clear status (e.g., "OK" or "ERROR: disk usage at 95%").
  • Conditional: Check the SSH output for error indicators. Use a condition like "output contains ERROR or output contains CRITICAL." You can also check for specific thresholds (e.g., disk usage over 90%).
  • Slack (error path): Post to #ops with an urgent message format. Include the server name, the specific error, and a timestamp. Use bold text or an alert emoji so it stands out.
  • Email (error path): Send to ONCALL_EMAIL with the full health check output. Include the server hostname, IP address, and the exact error details so the on-call engineer can start troubleshooting immediately.
  • Healthy path: Simply log the successful check. No notifications are sent — your team doesn't need to know when things are working fine.

What the output looks like​

When everything is healthy, the workflow runs silently every 15 minutes and logs "Server XYZ: OK." When there's a problem, the #ops Slack channel gets an instant alert: "ALERT: Server XYZ — disk usage at 95% on /data partition." The on-call engineer simultaneously gets an email with the full diagnostic output.

Build Your Own​

Ready to create your own workflows? Here are some tips to help you design effective automations.

Start simple, then add complexity​

Begin with just two or three steps. Get the basic flow working first, then layer on conditionals, loops, and error handling. A working simple workflow is better than a broken complex one.

Think about failure from the start​

Every workflow should answer the question: "What happens when something goes wrong?" Add error branches early. Send alert emails or Slack messages when steps fail. Your future self will thank you.

Use global variables for values that change​

Don't hard-code email addresses, server URLs, or threshold values directly into your workflow steps. Put them in global variables instead. That way, when a team member changes or a server moves, you update one place — not every workflow that uses it.

Name your steps clearly​

Give each step a descriptive name like "Fetch daily sales from PostgreSQL" instead of just "SQL Query." When you're debugging a failed workflow at 2 AM, clear names make all the difference.

Test with small data first​

Before pointing your workflow at the production database or the real SFTP server, test with a small sample. Use a test email address, a sandbox API, or a limited query. Verify the output is correct before scaling up.

Reuse patterns across workflows​

Notice how many examples above use the same pattern: do work, then notify on success and alert on failure. Once you've built one workflow with this pattern, duplicate it and swap out the middle steps for your new use case.

Check execution history regularly​

After your workflow has been running for a few days, review the execution history. Look for steps that take longer than expected, frequent errors, or unexpected output. Small tweaks early on prevent bigger issues down the road.