INT-14Core CrmLeafAdministrator

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.

Part 14 · Integrations8 min read

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.

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 changed or changed to operators.
Conditions can match every record, or be built from standard fields or your own custom fields, combined with AND/OR. 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 caps how deep that chain can go, a mass-update action is capped on how many rows it can touch, and each run has a time budget. 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: the maximum number of rules an account can have, and limits on how many conditions or actions a single rule can carry.

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

Go to: Settings → Module Settings

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: 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 — test with a record you know should, and one that should not, match.

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: Use the test-run feature to check the rule's logic against sample data before it runs against live records, then activate it.

What to verify: The dry run's outcome matches what you expected for that record.

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 changed or changed to.
Loop protection and a maximum chain depth exist specifically to stop rules from triggering each other indefinitely. If a rule seems to have stopped partway through a chain, check the execution log for a chain-depth cutoff before assuming it failed.
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: overdue-invoice nudge. A rule triggers when an Invoice is updated, checks whether its due date has passed and it is still unpaid, and emails the client a reminder with placeholders filled in from the invoice.

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 the maximum chain depth	Expected behaviour once the depth limit is reached. Simplify the chain if it needs to go further
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 a maximum chain depth, recorded in the execution log.

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. Per-plan caps limit both the number of rules and how many conditions or actions a single rule can carry.

Still need a hand?

Our support team answers on business days. Reference INT-14 so we can jump straight in.

Contact support