Auto-Calculated Tasks – How Status and % Complete Are Determined

A schedule task can be set to auto-calculate. Its dates, duration, % complete and status are then derived from the sub-tasks beneath it, so a parent (summary) task reports what is happening underneath it without anyone updating it by hand.

This article covers what auto-calculate takes over, exactly how the percentage is worked out under each Progress Type setting, how the status follows from it, and why RAG behaves differently from everything else.

What Auto-Calculate Changes on the Parent

The calculated fields become read-only on the parent — they appear greyed out, because any value you typed would be overwritten the next time a sub-task changed.

Auto-calculate is set per task. Projects can also switch on auto-calculate the parent when a sub-task is added, which makes a task auto-calculated the first time it is given a child and hands control back if its last child is removed.

Milestones and tasks linked to an external system (for example Jira or Azure DevOps) cannot be auto-calculated parents as their dates come from elsewhere.

Which Sub-Tasks Count

• Direct children only. A parent is calculated from the tasks immediately beneath it in the schedule outline. Where one of those is itself a summary task, it has already rolled up its own children, so totals build up level by level.

• L5 tasks are excluded entirely — from the parent's dates, its duration and its % complete. See Taking a task out of the roll-up below.

• Inactive and externally-scheduled tasks keep their own dates and are not driven by the parent.

How % Complete Is Calculated

Each sub-task is given a weight, so a bigger piece of work moves the parent more than a small one. Where the weight comes from is set by Progress Type, in the project's schedule settings:

Note. In Hours mode the weight is the hours allocated to a task, not the hours booked against it. Booked hours can still influence the result, but indirectly — see Where Booked Hours Fit In below.

The Calculation Logic

Only direct sub-tasks are involved. For each one:

1. Work out its share of the total — its own weight divided by the weight of all the sub-tasks together (its days out of the total days, or its hours out of the total hours).

2. Multiply that share by the sub-task's own % complete. That is its contribution.

3. Add the contributions together to get the parent's % complete.

share of a sub-task = its own weight ÷ the total weight of all sub-tasks
its contribution    = that share × its own % complete
parent %            = all the contributions added together

The result is rounded down. A parent standing at 99.7% displays 99%, and 100% appears only when the arithmetic lands exactly on 100.

Three weighting details worth knowing:

• Milestones, and the Zero Duration Milestones setting. A schedule can be set to show milestones as zero duration. Either way a milestone carries a weight of 1 in Duration mode: with the setting on its duration is 0 and the calculation substitutes 1 so the milestone is not ignored, and with the setting off a single-day milestone measures 1 working day anyway. So switching the setting does not move any parent percentage. It does not change parent dates either — a parent spans the earliest start and the latest end of its children, and a milestone falls on the same date under both settings. What it changes is the duration shown against the milestone itself (0 days rather than 1) and how auto-scheduling places the tasks that follow it. In Hours mode a milestone is weighted like anything else, on its allocated hours — which for most milestones is none, so it drops out of the calculation entirely.

• A sub-task with no allocated hours has a weight of zero in Hours mode. It contributes to neither side of the sum, so it is visible in the plan but absent from the calculation. If no sub-task has hours allocated, the total weight is zero and the parent reports 0% / Not Started however much work is going on underneath. A project that tracks percentages without allocating hours should stay on Duration.

Example in Practice

A parent task with two sub-tasks:

If calculated by Duration

• The total duration of both tasks is 15 days (10 + 5).

• Task A makes up two-thirds of the total time (10 of 15 days). Task B makes up one-third (5 of 15 days).

• Task A is halfway complete (50%). Task B is fully complete (100%).

• Fluid combines these:

  • Task A's contribution = 10/15 × 50% = 33.3%

  • Task B's contribution = 5/15 × 100% = 33.3%

• Added together the parent is 66.6% complete, and because the figure is rounded down it displays 66%.

If calculated by Hours

• The total allocated hours across both tasks is 120 (40 + 80).

• Task A is one-third of the effort (40 of 120 hours). Task B is two-thirds (80 of 120 hours).

• Task A is halfway complete (50%). Task B is fully complete (100%).

• Fluid combines these:

  • Task A's contribution = 40/120 × 50% = 16.6%

  • Task B's contribution = 80/120 × 100% = 66.6%

• Added together the parent is 83.3% complete, and rounded down it displays 83%.

What this shows

• With Duration, Task A carries more weight because it takes more time.

• With Hours, Task B carries more weight because it takes more effort.

• The same two sub-tasks at the same progress therefore give the parent a different percentage under each setting — which is why changing Progress Type mid-project visibly moves the numbers on every summary line.

Where Booked Hours Fit In

Where Flex Hours and Timesheets are both switched on, a task's own percentage is worked out from its timesheets — booked hours divided by allocated hours — and that figure is capped at 99%. Booking hours therefore never marks work as finished; a project manager confirms completion by setting the task to Completed.

The effect on a parent: if every sub-task percentage is coming from timesheet bookings, the parent cannot reach 100% either, so it stays In Progress at 99% or below. It completes once the sub-tasks are marked Completed, which takes their percentages to 100.

How Status Is Determined

A schedule task has four statuses: Not Started, In Progress, On Hold and Completed. Only Completed finishes a task.

The parent's status is worked out in two steps.

Step 1 — Are all sub-tasks finished? If every sub-task is Completed, the parent is treated as 100% whatever the individual percentages say. It goes to 100% / Completed, closes, and its RAG changes to Completed, recorded in its RAG history.

Step 2 — Otherwise the status follows the rolled-up percentage. Note that this step reaches the same outcome at 100%: a parent does not need every sub-task marked Completed to complete — it needs the percentages to add up to 100.

An auto-calculated parent therefore only ever shows Not Started, In Progress or Completed. It is never On Hold: no combination of sub-tasks produces that.

On Hold Sub-Tasks

On Hold is an open status — it pauses work rather than finishing it — and it behaves differently from the other three:

• It does not pause the parent. A paused sub-task below 100% simply leaves the parent In Progress along with everything else in flight. And because an On Hold task can hold 100%, a set of sub-tasks all standing at 100% takes the parent to Completed whether they are On Hold or Completed.

• It still counts in the percentage. An On Hold sub-task contributes its full weight and whatever percentage it holds, exactly as an In Progress one would.

• Its own percentage is left alone. Editing the percentage on an On Hold task stores the number and changes nothing else: 0% does not send it back to Not Started, and 100% does not complete it. Every other status keeps percentage and status in step — enter 100% against a Not Started or In Progress task and it becomes Completed; drop a Completed task to 60% and it becomes In Progress.

• It cannot make the parent read On Hold. One paused sub-task among others in flight simply leaves the parent In Progress.

Taking a Task Out of the Roll-Up

To keep a task in the plan but out of the parent's figures, set it to promotion level L5. An L5 task keeps its own dates, status and percentage, but every part of the parent's calculation skips it — the parent's dates, duration and % complete are all worked out as though the task were not there.

Use it for work that should not shape the summary: something parked indefinitely, a placeholder, or work tracked here for visibility but owned and reported elsewhere.

Before using L5. It removes a task from the completion check as well as the arithmetic. An unfinished L5 sub-task will not hold its parent open: once every non-L5 sub-task is Completed, the parent goes to 100%, closes and changes its RAG to Completed with the L5 work still outstanding. Set a task to L5 because it should not shape the parent, not to tidy away something that still needs doing.

If the parent task itself needs to be reported as On Hold, switch auto-calculate off on that parent, which returns its status, dates and percentage to manual control.

How a Parent Reaches 100% Without Every Sub-Task Being Completed

The percentage is a total of the sub-task percentages, and one status is allowed to hold 100% without being finished: On Hold. A sub-task parked at 100% while On Hold therefore counts as fully done in the arithmetic, so a parent can reach 100% even though that sub-task was never marked Completed. When it does, it completes like any other parent at 100%: the status reads Completed, the parent closes, and its RAG moves to Completed.

Reaching 100% is what completes a parent. It does not wait for every sub-task to carry the Completed status.

How RAG Is Determined

RAG is not rolled up. Fluid does not take the worst RAG of the sub-tasks, and an Amber or Red sub-task does not turn its parent Amber or Red. A summary task's RAG is the judgement of whoever owns that line.

Whether you can set it depends on one thing: the parent's status.

• Status is not Completed — the RAG is yours. Unlike the status, dates and % complete, which auto-calculate takes over, the RAG field stays editable on a summary task.

• Status is Completed — the RAG is locked, showing Completed, and cannot be changed by hand. This is what stops a task reading Completed with a Green or Red RAG beside it.

Two things change a parent's RAG automatically, and both are written to its RAG history:

Those are the only two ways a Completed RAG is set or cleared. To make the RAG editable again, the parent has to leave Completed — which for an auto-calculated parent means its roll-up falling back below 100%, when a sub-task is reopened or a new one is added. The second row above is that moment: the RAG unlocks and resets to the project default together.

Anything the owner sets in between — Green, Amber, Red — stays as set until they change it or the parent completes. Where governance requires a summary line to reflect problems beneath it, that is a review step rather than something the roll-up performs.

Worked Example — All Three Together

A summary line as it appears in the Gantt, with Progress Type set to Duration:

Reading the parent row:

• 66% — the three tasks total 9 days, so each contributes its share of those 9 days multiplied by its own progress: the extract 5/9 × 100% = 55.5%, the cleanse 2/9 × 50% = 11.1%, and the load 2/9 × 0% = 0%. Added together that is 66.6%, rounded down to 66. A simple average of 100, 50 and 0 would have given 50%; the parent sits higher because the extract is the longest task at 5 of the 9 days, so finishing it moves the parent more than either of the others could.

• In Progress — not every sub-task is Completed, so step 2 applies and 66% means In Progress. The parent will read Completed once the cleanse and the load reach 100%.

• Green, with an Amber sub-task beneath it — the roll-up neither sets this nor reconciles it. The Amber on the cleansing task does not reach the parent. The parent's Green is whatever its owner last set, or the project default it started on, and it changes on its own only when the roll-up reaches 100%, at which point it becomes Completed.

When the Figures Refresh

The roll-up runs when a sub-task is saved, has its percentage updated, is moved to another parent, is added or is deleted. It runs in the background, so a parent may take a few seconds to catch up and the page may need refreshing to show it. Importing a plan — from MS Project, for example — recalculates the whole schedule tree in one pass.

Because each level is calculated from its own direct children, a change deep in the plan works its way up level by level rather than all at once.