Allocation and utilisation

Utilisation is one of the easiest numbers in the platform to misread. It looks like a workload calculation and it is not one. Knowing exactly what it counts is the difference between using it to plan and being misled by it.

Utilisation is a sum of percentages

An allocation records that a person is on a project for some share of their time, between two dates. Their utilisation is the total of those shares across every allocation that is currently active.

Three projects at 50%, 40%, and 30% produce 120%. The pool shows the person in red and counts them under Over-allocated.

That is the whole calculation. There is no weighting, no priority, and no attempt to work out whether the commitments genuinely overlap beyond the date check.

Capacity in hours is recorded, not used

Every resource carries a capacity in hours per week, defaulting to 40. The card shows it and capacity forecasting sums it.

Nothing converts a percentage into hours. A person at 100% is fully allocated whether their capacity says 40 hours or 8. A part-time contractor at 50% of a 20-hour week and a full-timer at 50% of 40 hours are the same number here.

The practical consequence: use the percentage as a statement of commitment, and read capacity as separate context a human interprets. If you need “this person has twelve hours left”, the platform will not give it to you from allocations.

Workload is a different measure entirely

A project’s Workload section also shows utilisation, and it is calculated another way: from remaining estimated hours on the tasks assigned to each person, against a fixed assumption printed on screen — 100% equals 40 hours per week.

It does not read allocations, and it does not read the capacity on the resource. So the same person can be 120% in the resource pool and comfortable in Workload, or the reverse, without either being wrong. They are answering different questions:

• Pool utilisation: how much have we promised this person?
• Workload: how much work is sitting on them right now?

Neither is the truth on its own. A discrepancy between them is usually the interesting finding.

Allocations appear without anyone making them

Two paths create allocations as a side effect:

Assigning somebody a task on a board linked to a project adds them to that project’s team at 50%, creating a resource for them if they have none.

Sync from Tasks on the project’s Resources section does the same thing in bulk for everyone already assigned.

Both are convenient, and both mean the pool’s numbers can move without anybody opening either module. A person who picks up one task on three projects is showing 150% utilisation without a single deliberate allocation decision. When a figure looks wrong, this is usually why.

Team Calendar absences do not affect any of this

This is the one people expect and do not get. Marking somebody away in Team Calendar does not reduce their availability here, does not lower their utilisation, and does not warn you when you allocate them across their leave.

Absences feed the Away view and the Bookings availability check, and nothing else. Projects and Resources never read them.

If leave matters to your planning, end the allocation for that period or narrow its dates — the platform will not do it for you.

What follows from all this

The pool is good at one question: who have we promised to too much? It is not a capacity planner, and treating it as one produces confident numbers built on assumptions the platform never made.

To set allocations, see Allocate people to a project. For the fields behind them, see the resource fields reference.