Build an automation
When this happens, do that — the events you can trigger on, the conditions that gate them, and the actions they fire.
An automation is a rule. When something happens, Then do something, optionally only If certain conditions hold.
The point is to stop your firm running on people remembering things.
Where to find it
Rules can also be scoped to a single pipeline, in which case they live with that pipeline.
Build a rule
- Give it a name under Name this rule.
- Pick the When event.
- Add conditions, if the rule shouldn't fire every time.
- Pick the Then actions.
- Save.
Existing rules are searchable — Search your rules… — which matters once you have thirty.
Events you can trigger on
Events are grouped by what they concern: Tasks, Jobs, Compliance, Doc requests, Signatures, Payments, and Clients.
Some of the more useful ones:
- Task enters a status
- Task is assigned
- Task completed
- Subtask completed
- Task becomes overdue
- Task is due soon (3 days)
- Job completes
- Job is unblocked
- Deadline approaching
- Deadline overdue
- Doc request goes stale (5 days)
- All requested documents received
- A requested document is received
- Signature completes
- Signature is declined
- Payment is received
- Client uploads / responds
- Client group ready to contact
Task enters a status can be set against a status role rather than a named status, which is what lets one rule cover every pipeline. A rule on the Waiting · client role fires no matter which pipeline the work came from.
Conditions
Conditions narrow when a rule applies. You can gate on pipeline, template, client, client group, tag, signature template, and entity type.
Gating on a client tag is the pattern worth knowing. Tag the twelve clients on monthly bookkeeping, then build rules that only apply to clients carrying that tag. It's how you get per-segment behaviour without building twelve rules.
Actions
Seven actions:
- Notify — tell someone.
- Advance status — move the work along.
- Assign — set the assignee.
- Add / remove tag — mark the task.
- Create task — spawn follow-on work.
- Start client reminder — begin a reminder sequence.
- Email client — send them something.
Recipients for notifications can be the Task assignee, the Client owner, Owners & admins, or a named person.
Client emails go to a review queue
Rules that email a client stage the message for a human to look at before it sends, rather than firing straight out.
That's deliberate. An automation that emails clients is exactly the thing you want working for you, and exactly the thing you don't want going out wrong two hundred times before anyone notices.
Testing and turning rules off
Rules can be Paused rather than deleted, which is the right move when you're not sure. Some rules are marked System, and those ship with LedgerOS.
There's a run history showing what fired and when. Check it after building anything non-trivial, rather than assuming silence means it worked.
Notes and limits
- A rule that would fire on its own action doesn't loop indefinitely, but rules that trigger each other are worth avoiding.
- Manual moves are distinguished from automated ones in the flow, so you can see what moved by itself.
- Paused rules keep their configuration and can be resumed unchanged.
- Deleting a rule doesn't undo anything it already did.