Subtasks and dependencies: putting the order of work into your CRM

Thursday, 2:20 p.m. A service manager at a mid-sized maintenance company realises the job promised to a customer will not close this week. The task board shows one line: "Line 3 overhaul — March 12." An owner is assigned, a due date is set, the priority flag is red. But six steps are hiding inside that single line: order the part, receive the part, schedule the shift, send the crew, run the test, get the customer sign-off. The order went in two days late. Everything behind it slipped two days as well, and nobody saw it happen, because there was nowhere in the record for the slip to show up. One line, one date, one status.

This article opens that line up in order: what a single-line task hides, how to choose between a checklist item, a subtask and a standalone task, the difference between sequence and a genuine blocker, who writes the chain and when, what a Gantt view is for, what happens to dates when a link breaks, which work does not deserve a dependency, where handoffs stall, and how to retrofit dependencies onto a project already running.

What does a single-line task hide?

A task title usually makes a promise without describing a plan. "Line 3 overhaul" carries none of the steps living in the head of the person doing it. Memory is not a bad place to keep them — while that person is on the job, the work moves. The gap shows up when they take a week off, or when the job is handed to a colleague.

Three things stay invisible in a one-line task. Sequence: which step has to come before which other one. Waiting: is the job stalled because we are slow, or because something has to arrive from outside? Handoff: when work passes between people, what exactly is delivered? When none of the three is written down, a task can sit in "in progress" for a month and nobody has technically lied — the status field is accurate.

Writing those three things down does not add complexity; it exposes complexity that already exists. In field service, nobody expects a work order running from the site to the invoice to fit in a single row. The same holds for a campaign launch or a proposal build — the difference is that in a workshop the steps are physically visible, and in an office they are not.

Subtasks and dependencies exist to close that gap. A subtask says "this job is made of these pieces." A dependency says "this piece cannot start until that piece is finished." They answer two separate questions, and most teams blur them together — which is why they either never break work down, or wire everything to everything and abandon the diagram a month later.

Checklist item, subtask or standalone task?

Once you decide to break a job down, the first question is not "how many pieces" but "what weight." A checklist item has no owner, no date and no presence in reporting; it exists so nobody forgets. A subtask has an owner and a date but no meaning on its own. A standalone task is a commitment that stands up by itself, with its own deadline and its own line in a report.

Three tests settle it in practice. Does this piece have a different owner from the parent? Does it need its own date? Does someone else's work start the moment it finishes? Three noes mean a checklist item is enough; one yes justifies a subtask; three yeses mean the piece has outgrown the parent.

Situation	Right format	Why
Same person, same day, steps of a few minutes each	Checklist item	Repeating owner and date just adds noise
Different owner, shared delivery date	Subtask	Responsibility splits, the target stays common
Different owner, different date, order is mandatory	Subtask plus dependency	A slip has to travel down the chain
Reported on its own, promised to a customer	Standalone task	It must stay tracked after the parent closes
The same step set every month	Template or recurring task	Rebuilding it by hand always loses a step

You do not have to reason through this table every time. The second time you build the same breakdown by hand, it has become a pattern worth saving as a reusable task template — one that carries the step list and the order between the steps together, which is the part teams forget to keep.

Wording matters as much as format. "Prepare the design" is not a subtask, it is a wish. Without an acceptance criterion, a delivery format and a named recipient, the next link sends the work back. A good subtask description reads much like the brief you hand a writer: what, for whom, in what shape, by when.

Is a dependency a sequence or a blocker?

This is the distinction people skip most often. Chronological sequence describes the week in which we intend to do things; a blocker is a step that physically or logically cannot begin. Record them as the same thing and the plan turns rigid: two jobs that could run side by side start waiting for each other because someone wrote them one after the other.

One question settles it. "If the previous job had not finished today, could this one still have started today?" If yes, you have a preference, not a dependency. If no, the dependency is real and belongs in the record. In service work the answer is usually blunt: until the part is issued from service stock, the installation step cannot begin — and what is being waited on there is material, not a person.

Most dependencies are finish-to-start. Less often you want start-to-start, where two jobs have to move together. There is a third category people rarely model: waiting time, when nobody is working but the calendar is still burning — a contract sitting with legal, a shipment in transit, a lab result. Logging waiting time feels wrong, but leaving it out means your plan assumes a speed nobody ever achieves.

Who writes the chain, and when?

A dependency added after the fact is an explanation, not a plan. Saying "this was actually blocked by that" once the job has stalled changes nothing. The chain has to be built on the day the work starts, by whoever opened the project. That does not require a detailed schedule — the first pass only answers "which step is waiting on which," and durations firm up later.

The chain should be written by whoever is accountable for the outcome, not by the person performing each step; specialists put their own step at the centre and stop seeing past it. In Rocketly's task management, Subtasks & Dependencies keeps that decision on the task record itself, so "which task is waiting on which" lives on the work rather than in a meeting note — and when the order changes, Activity History records who changed it.

The first draft of a chain usually comes out of a meeting, which is exactly where it tends to die as a note. Hence the value of turning meeting output into action items rather than minutes: if the sequence agreed in the room has not become tasks and links by the time the call ends, you will agree to it again next week.

What are you actually reading in a Gantt view?

A Gantt view is not a decorative calendar; it exists so you can read the length of a chain. When the same task pool opens as a board, a list, a calendar or a Gantt, each view answers a different question. The board answers "where is everything right now," the list "who is carrying what," the calendar "what lands this week." Gantt answers one thing only: which steps determine how long this project takes?

The longest connected path through a project is its real duration. A one-day slip on that path delays the project by a day; a three-day slip off it changes nothing. Teams that cannot see the difference accelerate the wrong thing — squeezing a step that already had slack while the bottleneck goes untouched.

The same reading applies on the revenue side. Deal stages are a dependency chain too: no proposal before the demo, no negotiation before the proposal lands. Designing pipeline stages properly is the sales-side version of the same discipline.

What happens to dates when a link breaks?

The value of a chain shows up when the plan fails, not while it holds. The step in front slipped — what happens to the four behind it? Three wrong answers: leave every date untouched, so the board starts lying; push each one by hand, which nobody sustains; or hold the delivery date and compress the middle, which becomes unplanned overtime that surfaces at the end.

The right answer is to let the slip live visibly on the record. When a reminder is pushed with a written reason, that reason lands in the reminder history, so a month later "why did this move" is answered by the record rather than by recollection. This is why Deferral with a Reason is a distinct step in Rocketly, and why an Escalation Policy hands an unanswered reminder to a backup once a time threshold passes.

Delays caused by waiting deserve their own category, because the fix is not inside your team. A step sitting with the other side's approver says nothing about your throughput. The gap is sharpest in tracking a contract from signature to renewal, where most of the elapsed time belongs to someone else's legal desk and has to be measured separately.

Which work does not deserve a dependency?

Dependencies are not free. Every link is a rule that needs maintenance: reviewed when a date moves, cleared when a job is cancelled, quietly misleading when it was wrong to begin with. "Link everything" fails as badly as linking nothing — a forty-node chain nobody has opened in three weeks is a common outcome.

Skip the dependency in three cases. When the two jobs genuinely can run in parallel. When the order changes every time, which means you have a habit rather than a rule. And when the step is so short that tracking it costs more than doing it. For routine, predictable work, automation beats decomposition: firing repetitive sales tasks from no-code triggers is cheaper and more reliable than redrawing the same chain by hand every month.

A rough threshold helps. If a single job accumulates more than about six dependency links underneath it, it is probably not a task any more — it is a project. Move it up a level; keeping it at task level distorts both the board and the reports.

Where does work quietly stall between people?

The fragile part of a chain is not inside the steps, it is between them. One person has finished, the next has not picked the work up, and nobody has either claimed it or refused it. In delay statistics that gap gets charged to the final step, which makes the wrong person look slow.

Making handoffs visible starts with assigning subtask owners independently of the parent. Once "who holds this, and when did that change" is recorded, "I wasn't told" becomes a measurable event rather than a debate. The Task Workload report and the team summary in the Workspace ask the same question from above: who is carrying how much open work, where the pile-up started, and who has become the bottleneck.

The gaps stretch further when the team is not in one room, because the question that used to get asked in a corridor now goes unasked. Building visibility and rhythm in a distributed team begins precisely at these handoff moments: who took delivery of what, when they took it, and what they are still waiting on.

In what order do you retrofit dependencies to a live project?

You do not need to stop the work and remodel it. Five steps cover most teams. First, pick the three jobs that have slipped the most; the benefit has already accumulated there. Second, write one sentence for each: what is this job waiting on right now? Third, check whether that thing exists in the system as a task — if it does not, create it, because you cannot depend on something with no record.

Fourth, create the links and realign dates to the chain; bulk actions fix the dates that no longer fit faster and more consistently than clicking through them one by one. Fifth, block real working time in the calendar. A due date says when the work is owed; a time block says when it will actually be done, and separating the two moves a plan closer to reality.

Two weeks later, open the Task Durations report. The gap between estimated and actual time tells you where the chain was wired wrong better than any conversation will. You do not have to keep that measurement in a separate project tool — detach the work from the customer record and the context goes with it, while a stack spread across ten separate apps needs more maintenance than the chain it was meant to manage.

If you want to try this sequence on your own work, create a free Rocketly account and build the first chain on a single job that has already slipped.

FAQ

Are subtasks and dependencies the same thing?

No. A subtask shows what a job is made of; a dependency sets the order between pieces. You can split a job into subtasks and link none of them — if the pieces run in parallel, that is the correct answer. The reverse also happens: two independent tasks can be linked without any parent-child relationship.

Doesn't adding dependencies make the plan rigid?

Only when they are wrong. Recording chronological preferences as dependencies forces work that could run side by side into a queue. The test is single: if the earlier job had not finished, could this one have started? If yes, do not create the link.

What should I do if a task in the chain is cancelled?

Close it as cancelled rather than deleting it, and review the links behind it — otherwise the steps waiting on it never start. A task or project deleted by mistake can be restored from the trash, but closing keeps the reasoning visible in the record, which deletion does not.

Is this breakdown too heavy for a small team?

Decomposing every job in a three-person team is wasted effort. The working rule: build chains only where work changes hands or waits on something external. That is usually a small share of the work — and the source of most of the delays.