How to Automate Records with Workflow Automation in CrmLeaf
All editions. Requires the WorkflowAutomation add-on module. It ships off — an Administrator must enable it, and per-plan caps limit how many rules an account can run and how large each rule can be.
Availability: All editions. Requires the WorkflowAutomation add-on module. It ships off — an Administrator must enable it, and per-plan caps limit how many rules an account can run and how large each rule can be.
What's New NEW
R26.09 · Sep 2026Workflow Automation is a new add-on: a no-code "When → If → Then" rules engine that watches records across eight record types and can notify, email, assign, create a follow-up task, update a field, or call an outbound webhook automatically when something changes.
R26.10 · Oct 2026The published Workflow Automation help now documents the limits that apply to every rule: conditions are always combined with AND (there is no OR), a chain of rules stops at three rules deep, a bulk update that changes more than 200 records runs no rules at all, and a single run stops starting new actions after about 45 seconds. A Test Run in the builder shows whether a rule would run against one of your five newest records without saving or doing anything.
Overview
Workflow Automation lets you describe a rule instead of doing the repetitive part of it by hand: when a record is created or updated, if it matches conditions you set, then CrmLeaf runs one or more actions automatically. It covers eight record types — Lead, Deal, Client, Task, Ticket, Proposal, Invoice and Project — and every rule keeps a run log, so you can see exactly what fired and what it did.
How It Works
A rule has three parts: a trigger (record created or updated), conditions (what must be true about that record), and one or more actions (what happens next). Rules fire no matter how the change happened — the web app, the mobile app, the public API, an AI assistant through MCP, or a background job all count.
Record created or updated → Conditions checked → Actions run → Execution logged
- Eight record types are covered: Lead, Deal, Client, Task, Ticket, Proposal, Invoice and Project. HR/employee records are deliberately excluded pending a data-exposure review, so you cannot build a rule against employee data.
- Two triggers only: a record is created, or a record is updated.
There is no separate "status changed" trigger — a status or field change is expressed as a condition on the
"updated" trigger, using
changedorchanged tooperators. - Conditions can match every record, or be built from standard fields or your own custom fields. Conditions are always combined with AND: every condition must be true for the rule to run, and there is no OR. To cover alternatives, build a separate rule for each one. The available comparisons are equals, not-equals, greater-than, less-than, contains, is-empty, is-not-empty, changed, and changed-to.
- Six actions are available: send an in-app notification, send an email (with placeholders that fill in from the record), assign the owner or assignee, create a follow-up task, update a field on the record, or call an outbound webhook. A webhook action is hardened against SSRF.
- Actions run in an order you choose, under one of three modes: sequence (run every action regardless of earlier results), bailout (stop the rest as soon as one action fails), or parallel (run them all at once).
- Safety rails are built in: loop protection detects a chain of rules triggering each other and stops the chain at three rules deep; if one bulk update changes more than 200 records, no rules run for it; and a single run stops starting new actions after about 45 seconds. Every run — including one that was skipped or chained from another rule — writes an entry to the execution log.
- A template gallery offers ready-made rules across sales, finance, projects, support, solar and integrations categories, alongside the visual When/If/Then builder for a rule built from scratch. A test-run (dry run) lets you check a rule's logic before it runs for real.
- Per-plan caps apply on top of the module being enabled: your plan sets how many active rules, conditions and actions you can have.
- Rules run on a change, not on a clock. The only triggers are a record being created or updated, so a rule cannot fire simply because a date passes with nobody touching the record.
Who Can Use This Feature?
Administrator
- Enable the Workflow Automation module for the account.
- Build, edit and delete rules using the visual When/If/Then builder or a template from the gallery.
- Test a rule with a dry run before switching it on for real records.
- Review the execution log to confirm a rule is behaving as intended, and adjust or disable it if not.
Building and managing rules is governed by five ownership-scoped permissions (add, view, edit, delete and manage settings for Workflow Automation), so a company can delegate rule-building to specific roles rather than restricting it to a single Administrator account.
Prerequisites
- The Workflow Automation module enabled for the account, and confirmation of your plan's rule and per-rule action/condition caps.
- A clear, written statement of what should happen and when, so the rule is built around a real trigger and condition rather than "notify on everything."
- For an email or notification action, the message content and any placeholders it should fill in.
- For a webhook action, a destination URL you control and a technical contact who can confirm it received the call.
For Administrators
Step 1: Enable the module
What to do: Enable the Workflow Automation module for the account.
What to verify: The Workflow Automation area becomes available, and it shows your plan's rule limit.
Step 2: Start from a template or build from scratch
What to do: Browse the template gallery for a rule close to what you need, or start a new rule in the visual builder. To start a new rule, choose Add automation, open the arrow beside it, and select Start from scratch; to change an existing rule, select Edit on its row. The builder runs through name, When, If, Then, Test Run and Save: pick the record type, the trigger (created or updated), and the conditions.
What to verify: The conditions describe the exact situation you want to catch. Remember they are all combined with AND, so a situation with alternatives needs one rule per alternative.
Step 3: Add actions and choose how they run
What to do: Add one or more actions (notify, email, assign, create task, update field, or webhook), order them, and choose sequence, bailout, or parallel depending on whether later actions depend on earlier ones succeeding.
What to verify: The order and mode match what should happen if one action fails partway through.
Step 4: Dry-run, then activate
What to do: Select Test Run and choose a record from the five newest records of that type. The test reports which conditions passed or failed, shows the actual field values, and says whether the rule would run or would not run. Nothing is saved and no action is performed. When you are satisfied, save the rule.
What to verify: The test result matches what you expected for that record, including a record that should not match.
Step 5: Monitor the execution log
What to do: After the rule has been live for a while, review its execution log for runs that failed, were skipped, or chained into another rule.
What to verify: The rule is firing on the records you expect, at the rate you expect, with no runaway chains.
Expected Result
A configured rule fires automatically whenever a matching record is created or updated, runs its actions in the order and mode you chose, and every run — successful, failed, skipped, or chained — is visible in the execution log.
Important Notes
- Menu names and their position can differ between product editions and can be customised for your account, so your sidebar may not match these paths exactly. Use Search or your Quick Access items if you cannot find a screen.
- Workflow Automation is an add-on module and ships off. Confirm it is enabled and check your plan's rule and per-rule limits before building a process that depends on it.
- HR/employee records are deliberately excluded from automation pending a data-exposure review — you cannot build a rule against them.
- There is no separate "status changed" trigger. Express a status or field change as a condition on the
"updated" trigger using
changedorchanged to. - Loop protection exists specifically to stop rules from triggering each other indefinitely: a chain stops at three rules deep. If a rule seems to have stopped partway through a chain, check the execution log for that cutoff before assuming it failed.
- If a single bulk update changes more than 200 records, no rules run for it. Do not rely on a rule to catch records changed in a large bulk update.
- Rules fire when a record is created or updated. There is no time-based trigger, so a rule cannot send a reminder just because a due date has passed.
- A webhook action sends data outside CrmLeaf. Only send to destinations you control and that meet your data-protection obligations.
Common Scenarios
Example: auto-assign leads by territory. A rule triggers when a Lead is created, checks a custom "territory" field, and assigns the lead to the matching sales rep automatically instead of a manager doing it by hand.
Example: invoice paid. A rule triggers when an Invoice is updated, checks whether its status changed to the paid status, and sends the account owner an in-app notification with the invoice number filled in from the record. Because rules run on a change, a reminder about a due date that has passed with no edit to the invoice is not something a rule can send.
Example: kickoff task on a won deal. A rule triggers when a Deal is updated, checks whether its stage changed to the "Won" stage, and creates a follow-up onboarding task assigned to the delivery team.
Troubleshooting
| Issue | Possible Cause | Resolution |
|---|---|---|
| Workflow Automation cannot be found | The add-on module is not enabled for the account | Enable the module in module settings, or confirm plan inclusion |
| A new rule cannot be saved | The account has reached its plan's maximum number of rules, or the rule exceeds a per-rule condition/action cap | Remove or consolidate an existing rule, or check your plan's limits |
| A rule did not fire on a record that should have matched | The trigger, condition, or a custom-field reference does not match what actually changed on the record | Re-check the condition against the execution log, or dry-run the rule against that exact record |
| A rule seems to have stopped partway through a chain of other rules | Loop protection cut the chain off at three rules deep | Expected behaviour once the depth limit is reached. Simplify the chain if it needs to go further |
| No rules ran after a large bulk update | The bulk update changed more than 200 records, and no rules run in that case | Make the change in smaller batches, or handle those records by hand |
| A run stopped before all its actions finished | A run stops starting new actions after about 45 seconds | Split the work across fewer or lighter actions, and check the execution log for what completed |
| A rule needs to match either of two conditions | Conditions are always combined with AND, and there is no OR | Build one rule for each alternative |
| An action failed but later actions still ran | The rule is set to sequence mode, which runs every action regardless of earlier failures | Switch to bailout mode if later actions should depend on earlier ones succeeding |
Frequently Asked Questions
Can a rule watch employee or HR records?
No. HR/employee records are deliberately excluded from Workflow Automation pending a data-exposure review.
Is there a trigger specifically for a status change?
No. Express it as a condition on the "updated" trigger using the changed or changed to
operators.
What stops two rules from triggering each other forever?
Loop protection detects a chain of rules triggering one another and stops it at three rules deep, recorded in the execution log.
Can a condition use OR?
No. Conditions are always combined with AND. To cover alternatives, build a separate rule for each.
Can a rule run on a schedule, such as when an invoice becomes overdue?
No. A rule runs when a record is created or updated. There is no time-based trigger.
Does a rule fire only when someone uses the CrmLeaf web app?
No. A rule fires on the underlying record change regardless of source — the web app, the mobile app, the public API, an AI assistant through MCP, or a background job all count.
How many rules can my account have?
It depends on your plan. Your plan sets how many active rules, conditions and actions you can have.
Related Articles
Our support team answers on business days. Reference INT-14 so we can jump straight in.