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.