Workflow: deep, basic or none?

Not every system has workflow

Some practice management systems, including some popular cloud products, offer little more than matter opening templates, task lists and merged letters. Others have full workflow engines with branching logic, automatic steps and their own data screens. Neither is wrong. A small advisory practice may never need more than tasks and templates. A volume conveyancing or personal injury team may depend on workflow for almost every step.

The problem comes when a firm does not know which it is, or assumes every system works like the one it has.

What real workflow looks like

• Decisions: the next step depends on the answers, such as leasehold or freehold, mortgage or cash, fast track or multi-track.
• Automatic steps: documents, emails, tasks and key dates created without anyone clicking, triggered by dates, data changes or events such as a payment received.
• Its own data: custom screens that capture what each type of work needs, used by the workflow and by the documents it produces.
• Supervision: overdue steps visible to supervisors, and matters that cannot move on until a check is done.

If you are coming from a fully workflowed system

Many long-established, on-premises systems were built around workflow. Over twenty years, firms have automated almost everything in them, often without anyone now knowing quite how much. Moving to software as a service brings real benefits: nothing to install, no upgrades to manage, work from anywhere. But some cloud products were built for simplicity first, and the workflow the firm relies on may simply not exist.

The answer is not to stay put, and not to accept a step backwards. It is to know exactly what you rely on, and to test for it:

1. List your workflows, custom screens and precedents, and how often each is used.
2. Pick two or three of your most demanding processes and ask each vendor to build them, in front of you, running entirely in the browser.
3. Ask what runs on the vendor's servers and what depends on software on users' computers, such as macros or desktop add-ins.
4. Have one of your own team change the workflow after a short walkthrough. If only the vendor can change it, every improvement has a price.

The middle way: automation connected to the system

A simpler system can be extended with automation tools such as Microsoft Power Automate, through the system's API. That can work well, but the logic then lives in two places. Someone has to own it, monitor it and document it, and the API has to expose the data and events you need.

Workflows do not migrate

Data can be migrated. Workflow logic, in practice, cannot: every system models it differently. Plan to redesign each matter type, deciding what becomes automated workflow, what becomes a simple checklist and what is retired. Copying the old workflows step for step brings the old workarounds with them.

What to ask, and what to see

1. Show one of our workflows, including a decision and an automatic step, configured in front of us.
2. What triggers a step: only a user, or also dates, data changes and events?
3. Does everything run in the browser, with nothing installed?
4. Who can change workflows, and what does each change cost?
5. How will our existing workflows be redesigned, and is that in the proposal?