When / if / then
A trigger event, a condition check, and a named action — every rule reads the same way.
Rules that run the chase for you
Every automation follows the same shape: when something happens, if a condition holds, then take a named action. Nothing runs invisibly, and nothing an automation does is a judgment call.
Gentle reminder cadence
- WhenPack issued and incomplete
- If3 days before dueClient has not opened in 48h
- ThenSend branded reminder (email + SMS)Stop when pack completes
Last run 14 min ago · every run is logged with inputs and outcome
The rule model: when, if, then
Every automation in Cohesio breaks into three parts. The trigger is a named event — an engagement issued, a pack completing, an item sitting unreviewed, a month closing. The condition is a check against the current state of that engagement or client — a tag, a document type, a time elapsed. The action is what happens once both are true — a message sent, an assignment made, an entry added to the audit trail. Nothing fires without a trigger event actually occurring, and a rule with conditions that never match simply never acts, which is exactly the point: a firm can build a rule for a rare situation and trust it to sit quietly until that situation happens.
Eight recipes, with the exact conditions behind them
These are concrete starting points, each editable once created:
- Due-date reminder. When a requirement is 3 days from its due date, if it’s still outstanding, send a branded email and SMS reminder.
- Inactivity nudge. When 48 hours pass with no client activity on an open checklist, if at least one item remains outstanding, send one follow-up message — capped at once per window so a quiet client isn’t messaged repeatedly.
- Priority exception routing. When a submission is flagged as an exception, if the requirement is payroll or bank-related and the client carries a Priority tag, assign the exception to the client’s named owner and post to a designated channel.
- Review SLA escalation. When an item has sat unreviewed, if two business days pass with no decision recorded, escalate to the firm admin and log the breach permanently.
- Auto-draft next month. When a monthly engagement is handed off, if its template is marked recurring, draft the next month’s engagement and push the signed manifest to the connected ledger.
- Seasonal requirement skip. When a recurring engagement is about to draft, if the client is marked closed or seasonal for that specific month, omit the payroll requirement from that one cycle without altering the template itself.
- First-engagement welcome. When an onboarding engagement is issued, if it’s the client’s first engagement with the firm, send a short welcome message and create a kickoff task to schedule an intro call.
- Conflicting resubmission catch. When a client submits a new file for a requirement already accepted, if the new total disagrees with the accepted one, raise an exception instead of silently replacing the accepted evidence.
The run log: what gets recorded every time
Each time a rule fires, that run writes an entry showing the exact event that triggered it, which conditions were evaluated and whether they matched, what actions actually executed, and a timestamp. That entry lives under the rule itself, not buried in a generic activity feed you’d have to filter through — opening a rule shows its own history directly, which matters when you’re trying to answer a specific question like "did the reminder actually go out on the 9th."
Safety rails: what a rule is never allowed to do
Automations act only on named, observable events — a pack completing, a due date arriving, a submission conflicting with an accepted value. They never evaluate the content of a document or a submitted answer to decide anything; that judgment stays entirely with extraction proposing evidence and a person deciding on it. A rule cannot accept a submission, waive a requirement, or mark an engagement complete — those three actions require a named reviewer regardless of how automation is configured. This boundary exists so that "the AI sent something" is never a sentence anyone at your firm has to say about a client-facing message; every outbound communication traces back to a rule a staff member built and can read in full.
Rate limits keep a misconfigured rule from becoming a problem
Because a rule could theoretically fire on every item in a large pack at once, message-sending actions are capped per client per day regardless of how many separate rules or conditions would otherwise trigger a send. That cap protects a client from receiving a burst of near-identical messages if two overlapping rules both match the same event, and it protects a firm from a configuration mistake turning into a flood of reminders overnight.
Worked example
A fictional seasonal client, a lakeside ice cream shop called Frost Point, closes every July and runs no payroll that month. Without any special handling, the monthly template would still draft a payroll requirement in July, the client would have nothing to submit against it, and it would sit outstanding until someone manually waived it — the same manual step, every single July.
Instead, the firm sets up the seasonal-skip recipe with a condition scoped to this one client and the month of July. When the June engagement closes and July’s engagement is about to draft, the rule checks the condition, confirms the client is tagged seasonal for July, and omits the payroll requirement from that cycle only — every other requirement, including the bank statement, still drafts normally. The rule’s run log shows exactly which requirement was omitted and why, so a reviewer glancing at July’s checklist later sees a deliberate, recorded decision rather than a missing item that looks like an oversight.
Named events, visible logic, no hidden judgment
Eight starting recipes
Reminders, routing, SLAs, seasonal skips and more, ready to adjust to your firm’s conditions.
No document judgment
Rules act on events like a pack completing — never on reading or interpreting a submission’s content.
Rate-limited by design
Message-sending actions cap per client per day, so overlapping rules can’t flood one inbox.
Every automation run is logged, start to finish
Automations carry the same accountability as a person: each run records what triggered it, which conditions matched, what actions fired, and when. SLA breaches escalate to a named admin instead of aging quietly in a queue.
- Run history is visible per rule, not buried in a generic activity feed
- Pausing a rule preserves its history — nothing is lost
- SLA breaches write directly to the immutable audit trail
Rules, permissions and limits
Firm admins can create, edit, pause and delete rules. Reviewers can see which rules are active and read the run history for context, but they can’t change a rule’s trigger or actions without admin access.
Deleting a rule removes it from the active list but its past runs stay in the audit trail permanently — deleting a rule doesn’t erase the record of what it already did while it was active.
Yes. If two rules both listen for the same event — say, a pack completing — and their conditions both match, both fire independently. There’s no built-in exclusivity that forces you to choose only one rule per event.
Workspace doesn’t include rule automation at all. Team and Scale both support building as many rules as a firm’s workflow needs — the constraint that matters in practice is the messaging and processing volume caps tied to your plan, not a rule count.
A newly created rule can be left paused while you review its trigger and conditions against a real client’s data without it taking any action, then switched on once you’ve confirmed it matches what you intended.
Put the chase on autopilot
Start your free 7-day trial of the Team plan — automations included, no credit card required.