Workflow rules
The built-in automations cover the things almost every firm wants: routing, checklists, assignment, notifications. Workflow rules are where you add your own on top: a way to say "whenever this happens, do that" and have Journey carry it out. They're how a firm encodes the little habits that make its process its own, without anyone having to remember to perform them.
What it does
A workflow rule watches for an event and runs an action when it occurs. You might send your team a notification whenever a return goes stale, or email a client from one of your templates the moment their engagement letter is signed. Each rule is a small, self-contained piece of automation, and every time one runs, Journey records it, so you can look at a return and see which rules fired on it and whether each succeeded or was skipped.
A rule is made of three parts: the event it watches for, an optional filter that narrows when it applies, and the action it takes.
Where to find it
Go to Settings, then Workflow, and look for the Automation rules card. Only owners and general managers can create, change or delete rules, since a rule can send mail to your clients on your firm's behalf.
The events a rule can watch
Rules can respond to a range of moments in a return's or client's life:
- A return reaches a particular stage.
- A return goes stale at a stage.
- A return becomes overdue.
- A document is uploaded.
- A questionnaire is completed.
- An engagement letter is signed.
- An invoice is paid.
- A client logs into the portal for the first time.
- Documents in, draft checked: a return's required documents are all in and every document has been read. This one is for firms that prepare returns in Journey. It carries whether the draft calculated or still has open questions, so you can choose to run the rule either way or only on one of the two. Each rule runs once per return: when a later document comes in and is read, a rule that already ran for that return does not run again. A rule set to only one of the two runs the first time the draft gives that answer, even if an earlier check gave the other one. Editing a rule does not make it run again on returns where it already ran; to run it again, create a new rule.
The actions a rule can take
There are five, and the first one is not what its short name suggests, so read it before you build a rule around it.
Create client task. This creates a to-do for the CLIENT, in their portal. It is not an internal task for a member of staff. When it runs, the client gets a portal notification headed "New task from your preparer" and an email from your firm. Use it to ask a client for something. Do not use it to remind your own team, because the person who hears about it is the client.
Send staff notification. This is the one for your own team. It raises a notification inside Journey and does not contact the client. When the rule's event is Return reaches a stage, each person can switch these off for themselves in Settings, under Notifications ("Workflow rule: a return reaches a stage"). It is on unless your firm's default or their own setting turns it off. Staff notifications from rules on any other event always arrive. Journey already sends its own "Documents in, draft checked" notification to whoever the return is assigned to, so a staff notification rule on that event is only needed to tell someone else.
Send email from template. Sends one of your firm's email templates. Use this when you want to control the wording rather than send the standard to-do email.
Assign a reviewer. Puts a reviewer on the return.
Advance return to next stage. Moves the return along the pipeline. Automation stops at In Review and will not go further on its own. The stages past it involve a client signature, a filing with a taxing authority, or closing the engagement, and those should be a person's decision rather than a rule's. A rule that tries will be recorded as refused, with the reason.
A rule needs a client for some of these to make sense. When there isn't one, the run is recorded as skipped rather than failing.
Narrowing a rule with a filter
Left unfiltered, a rule fires for everything that matches its event. A filter lets you scope it down: to a particular return type, so it only touches 1120-S returns, for example, or to a particular client tier. That's what lets you write rules that are specific to a segment of your book without affecting the rest.
How to set it up
Workflow rules are defined per firm: you build one by choosing the event, an optional filter, and the action. Rules are additive and evaluated independently, so you can layer several without them interfering: each simply runs when its own event fires. They're meant to complement the built-in automations, not replace them.
Before you turn a rule on, check which action you picked. A rule that emails every client is easy to build by accident if you read "Create client task" as an internal task, and it will reach real people the first time its event fires.
Good to know
When a rule can't complete (for instance, an action that needs a client but the ticket doesn't have one), it's recorded as skipped, with the reason, rather than failing loudly or leaving you guessing. That log of successes and skips is the place to look if a rule you expected to fire didn't seem to.