Different task lists for different case types in Clio

Not natively. An automated workflow's conditions are the matter's practice area (required), and optionally the responsible attorney. That is the whole condition set. A task list is applied whole, with no per-task conditions, and custom fields cannot be used as conditions at all. Clio does have a feature called conditional logic, but it belongs to document drafting and cannot touch a task list.

That distinction catches people out, so it is worth clearing up first: two different sets of readers arrive at this question, and only one of them is going to find what they came for here.

No part of Clio Manage branches

Worth stating plainly, because the answer is often given from the wrong product. Clio Manage has no conditional logic anywhere. Three places you might expect to find it:

The conditional logic people have heard about lives in two other Clio products.

Clio Draft, separately priced, driven from a Word add-in, has a genuine branching engine. You wrap template text in If / End tags and everything between them is inserted only when the condition is met. Two condition kinds: question conditions ask the drafter a multiple-choice question at draft time ("What is the ground for divorce?"), and triggered conditions are if/then tests against a field (IF the defendant's name EXISTS). Both support compound AND/OR logic, and conditions can be nested, so an inner condition is tested only when the outer one is true.

Clio Grow's document templates have a smaller version: a rule that shows or hides other form fields depending on whether a checkbox is ticked.

So Clio the company owns a real rules engine, existence tests, equality tests, boolean combination, nesting, and points it entirely at Word documents in a product you buy separately. Clio Manage, where your matters and task lists live, gets practice area and one optional attorney. There is no shared engine underneath: knowing how to write a nested condition in a Clio Draft template tells you nothing about branching a task list, because the second thing does not exist.

One cross-over worth knowing if you use both: Clio Draft splits a field's label from its text-to-merge value, and Clio's own guide warns that logic driven off a selection needs to know which of the two it is comparing. That is the same class of trap as matching a picklist by label instead of id, described in reading Clio custom fields in an automation.

So: if you wanted conditional document drafting, Clio sells it, and this page is not about it. If you wanted a task list in Clio Manage that changes shape depending on the matter, read on, that is a real gap, and the most common reason firms outgrow the native feature.

What "different task lists per case type" actually means

The requirement is almost always narrower than it sounds. Firms rarely need two unrelated lists; they need one list with two or three variations.

A concrete example, from probate. Fourteen tasks, of which eleven are identical every time. The three that vary:

• Testate matters need a will lodgement task. Intestate ones do not.
• Matters with real property need a title search and a valuation. Matters without do not.
• Contested matters need a notice to interested parties on a hard deadline. Uncontested ones need a simpler notification.

Three binary variables, eleven tasks in common. That is the shape of the problem, and it is why the native workarounds get expensive: Clio makes you express the eleven shared tasks once per combination.

The four workarounds

One task list per case type

The straightforward answer, and the right one when you have two or three variations and they are stable. Task lists carry a name, a description and a practice area, so scoping by practice area is native, and if your variations are practice areas, you get branching free.

Where it stops: the arithmetic, once the variation sits inside a practice area. The probate example above, testate/intestate × property/no property × contested/uncontested, is eight lists, each holding the same eleven tasks. Change a shared task title and you make eight edits, or you make one and quietly have eight lists that disagree. Clio's duplicate-list function copies the tasks with it, which makes creating the eight fast and keeping them identical no easier.

The failure is not that eight lists is a lot to build. It is that eight lists is a lot to keep identical, and nothing tells you when they drift.

A superset list, then delete what does not apply

Build one list containing every task any variation might need, apply it, and have whoever opens the matter delete the irrelevant ones.

Where it stops: it inverts the automation. Somebody now reviews fourteen tasks and makes three judgement calls on every matter, which is more decisions than typing the right nine would have taken. And the deletions are silent: nobody can tell later whether the title search task is absent because there is no real property or because someone deleted it by mistake.

Defensible as a stopgap for a week. Not a system.

Sub-stages that fan out

Split the stage. Instead of one Probate, Opening stage, create Probate, Opening (Testate) and Probate, Opening (Intestate), each with its own workflow and list.

Where it stops: your matter stages are now a data model rather than a description of where a matter is. Stage sets multiply with the same arithmetic as the lists, reporting by stage becomes meaningless, and the stage board is a real reporting surface, filterable by client, responsible attorney, originating attorney and responsible staff, so distorting it costs you something. Whoever moves the matter also has to know which branch it belongs to, so the condition still gets evaluated by a human, just earlier and with less information.

Zapier, Make or n8n

Read the matter, branch on a field, create tasks through the Clio Manage API. This is the only workaround that genuinely expresses the condition.

Where it stops: you own it. A three-variable branch is a scenario with eight paths, each creating up to fourteen tasks. Date arithmetic that respects your working week has to be built by hand. Errors are silent unless you build alerting. It works, plenty of firms run exactly this, but be clear-eyed that you have built internal software, and check who maintains it when the person who wrote it is on holiday. This is the same calculation laid out in the guide to Clio's automated workflows.

The arithmetic that decides it

One number tells you whether to stay native: how many templates would you need if you built every combination?

Multiply the options of each variable that changes the list. Two variables with two options each is four. Three is eight. Add a third option to any one of them and you are at twelve. Then multiply by the number of practice areas doing something similar.

Under four, build them natively and get on with your day, the maintenance is real but survivable, and you avoid taking on a dependency. Above eight, the shared tasks inside those templates will drift, and the drift is invisible until a matter gets the wrong list.

Somewhere around six is where firms stop building and start looking, which matches what we see: nobody buys a branching tool because branching is elegant. They buy it the week they find two templates that were supposed to be identical and were not.

When the workarounds stop working

Beyond the template count, three specific tells:

The condition depends on a field filled in after the stage change. If real property is recorded on day four but the workflow fires on day one, no native arrangement can get this right. The condition is not knowable when the trigger fires.

The variations have different deadlines, not just different tasks. A contested notice on a statutory clock is not the same task with a different title; it is a different date rule. Duplicating templates duplicates the date logic too, and date logic is where errors are expensive.

Nobody can tell you which template is authoritative. The moment the answer to "which one of these eight is the good one?" is a shrug, the native approach has already failed. It just has not caused a problem yet.

How Taskflow handles it

Taskflow templates hold branches: a task or a group of tasks included only when a condition on the Clio matter is true, a custom field value, a practice area, a matter field. The eleven shared tasks exist once, and the three variable ones carry their conditions, so the probate example is one template rather than eight. Branch conditions read the matter at the moment the tasks are created, and the run record shows which branches evaluated true, so you can see why a matter got the list it got. The branches documentation has the condition types and the evaluation order, and reading Clio custom fields in an automation covers what a condition can actually see.

Questions people also ask

Does Clio have conditional logic for task lists?

No, and not in Clio Manage at all. Task lists are applied whole, automated workflow conditions are practice area plus optionally responsible attorney, and Manage's document templates are merge-field only. The conditional logic engine is in Clio Draft, a separately priced product, with If/End tags, compound AND/OR and nested conditions; Clio Grow has a smaller checkbox show/hide rule on its document templates.

Can a Clio Manage document template include a clause conditionally?

No. Clio Manage document templates work by merge-field substitution only, Word, Excel, PowerPoint and PDF files with merge-field codes, which do accept every custom field type as long as the field has been added to the matter. There is no mechanism to include or exclude a block of text: a merge field with no value renders blank rather than removing the sentence around it. Conditional clauses require Clio Draft.

Can an automated workflow choose between two task lists?

No. One rule applies one task list. To get two outcomes you need two rules, which is fine if the deciding factor is the practice area or the responsible attorney, and needs the sub-stage workaround if it is anything else.

Can a Clio automated workflow read a custom field?

Not as a condition. Custom fields are visible on the matter and both filterable and readable through the Manage API, but an automated workflow's condition set is practice area plus optional responsible attorney. Branching on a custom field requires something outside Clio, see reading Clio custom fields in an automation.

Can we use practice areas instead of case types?

Sometimes, and it is worth checking before anything more complicated. Automated workflows are already scoped per practice area, so if your variations map cleanly onto practice areas you get branching free. It breaks down when the variation is inside a practice area, testate versus intestate probate is not two practice areas, and making it two distorts every report you run.

Is there a limit on how many task lists Clio allows?

We have not found a documented cap on task lists. There is one on the automations that apply them: Clio Manage allows up to 1,000 automations per firm account. Either way the binding constraint is maintenance, firms lose track of near-identical templates long before they run out of room for them.

What is the fastest native setup for two case types?

Two task lists, two stages, two workflows, and a naming convention that puts the variable first, Probate — Opening (Testate) rather than Testate probate opening. It sorts correctly, and it makes an eight-template list readable at a glance instead of a wall of similar names.