Sub-tasks

What Sub-tasks Are

A sub-task is a piece of work attached to a record — something a person has to do before that record can move on.

Where to find it

Architect Panel → Data:

• Sub-tasks — checklist items against a record

Architect Panel → Automation:

• Worklist — everything assigned to you across records

What a sub-task holds

Its own record number, the record it belongs to, a title and description, an assignee and a team, a status, a due date and a completion date, who created it and when — and, where it came from something else, the module that produced it and any approval it relates to.

It belongs to a record

Which is the point. A sub-task is not a standalone to-do; it is work in the context of a case, a job, an order. Anybody looking at that record sees what is outstanding on it.

Assignee or team

Both are available. A team assignment is right where anybody in the team can do it and somebody will pick it up; an individual assignment is right where a specific person must.

Assigning everything to individuals produces work stuck behind one person’s absence. Assigning everything to teams produces work nobody picks up. Use both deliberately.

They can be generated

Sub-tasks record the module that created them, so they can come from an approval, a workflow, a checklist or a process rather than always being typed by hand.

That is what turns a documented procedure into visible, assignable work.

Due dates make them real

A sub-task without one is a suggestion. With one it appears in a worklist, can be chased, and can be reported on.

Keep them small

A sub-task should be one action by one person. "Complete the assessment" is a project; "book the site visit" is a sub-task.

Large sub-tasks sit at half-done for weeks and tell you nothing.

Completion should mean something

Agree what "done" means for each type of sub-task. Sub-tasks completed because they had been open too long are worse than no sub-tasks, because the record now claims the work happened.

Do not use them as a general to-do list

They belong to records. Personal reminders unconnected to anything clutter the list and make the genuinely outstanding work harder to see.

Worked example

A case type generates four sub-tasks on creation — acknowledge, assess, contact the customer, record the outcome — each assigned to a team with a due date derived from the case. Anybody opening the case sees exactly what is outstanding.

Recommendations

• One action, one person, per sub-task.
• Teams where anybody can act, individuals where they cannot.
• Always set a due date.
• Generate them from your process rather than typing them.

Working with Sub-tasks

Sub-tasks are only useful if the list reflects reality. That takes a small amount of discipline.

Where to find it

Architect Panel → Data:

• Sub-tasks — checklist items against a record

Architect Panel → Automation:

• Worklist — your outstanding work across every record

Work from the worklist

Not from the record. The worklist gathers what is assigned to you across every record, which is how somebody actually works — by what is due, not by opening cases one at a time.

Complete them at the time

Not at the end of the week. A list completed retrospectively is a list that was never used, and the completion dates are fiction — which matters if anybody ever relies on them.

Reassign rather than leaving

Somebody on leave with eleven open sub-tasks is eleven pieces of work nobody is doing. Reassigning to a team is usually the right move, and it should be routine rather than an escalation.

Chase by due date

Overdue sub-tasks are the operational picture. A weekly look at what is overdue, by team, finds both the work that has stalled and the process steps that are consistently unrealistic.

Watch what is always late

If one generated sub-task is overdue on most records, the due period is wrong or the step does not fit how people actually work. That is a process finding, not a performance one.

Cancel what is not needed

Generated sub-tasks sometimes do not apply. Cancelling with a reason is honest; completing something that was never done is not, and it corrupts everything you might later report.

Do not generate too many

A process producing fifteen sub-tasks per record produces a list people stop reading. Generate the steps that genuinely need tracking and leave the rest to the person doing the work.

Report on the shape, not the count

How long each type of sub-task takes, which stall, which are always late. The total number outstanding is a number that goes up and down; the pattern tells you what to change.

Review the generated set periodically

Processes change and the sub-tasks generated for them frequently do not. A step nobody does any more still appears, gets completed without being done, and quietly makes the data meaningless.

Worked example

A team works from the worklist and reviews overdue sub-tasks weekly. One generated step was overdue on most cases; investigation showed it depended on information that only arrives later, so the due period was changed and the step moved after the one it depended on.

Recommendations

• Work from the worklist, not record by record.
• Complete at the time, or the dates are fiction.
• Cancel with a reason rather than falsely completing.
• Investigate what is always late as a process problem.