Setting a role's demand

Flowtly Editorial Team4 min

A role's demand is what the work needs, stated separately from who is doing it. It is the number the Resourcing grid measures every booking against, and it is the reason an unfilled job shows up as a gap instead of as nothing at all.

Demand is set per role, per project, and it does not change when you staff the role. Booking someone answers who; demand answers how much, and the difference between the two is the shortfall the grid draws for you.

Declaring what a role needs

On the capacity grid, every role row carries a people icon at its right-hand edge. Select it to open the role's demand.

The dialog asks three things:

  • People needed — how many full-time people the role calls for. Whole numbers are the common case; 0.5 means half of one person's week, so 2.5 is two full-time people and a half.
  • Needed from and Needed until — the period the demand covers. If the role already has demand, these start on the period it already runs over; otherwise they start on the period currently on screen.

Below the fields, the dialog states what your number becomes: Open slots: 3 · 250% in total. That line matters, because demand is stored as one slot per full-time person — 2.5 people is three slots — and those slots are what the grid counts. Nothing appears on the grid that the dialog did not name first.

Select Save demand, and the role's cells update: the target line moves, and any week where the people booked fall short of it reads as a gap.

Adjusting demand later

Open the same dialog on a role that already has demand and the fields arrive filled in with what it currently says. Change the number, the period, or both.

Saving keeps the slots the role already has wherever it can and adjusts them, rather than tearing the role's demand down and rebuilding it. Raising demand from two people to three adds one slot; lowering it from three to two removes one. This is why the ids behind a role's demand stay stable across an edit, and why an adjustment is a small change rather than a large one.

If the role's existing slots run over different periods — which happens when demand arrived from an imported plan rather than from this dialog — the dialog says so before you save, because saving applies the single period above to all of them.

Withdrawing demand

Set People needed to 0 and save. The role stops declaring anything, and its cells stop reporting a gap.

The dialog warns you before this happens, and the warning names the one thing worth knowing: anyone already booked on the role stays booked. Withdrawing demand retires the requirement, not the people. If you meant to remove the bookings too, remove them separately — see The bench and draft bookings.

What to expect

  • A role with no declared demand is treated as one full-time person. That is the sensible default, not a statement you made. If the work genuinely needs half a week, say so here and the grid will stop reporting a shortfall that was never real.
  • Demand can exceed anyone's capacity, on purpose. A role may need four people; that is a statement about the work, not about a person, so nothing refuses it. The capacity limit applies to individuals — see capacity by project.
  • One role can take at most 20 people per save. Beyond that, the work is better described as several roles, and the plan is easier to read that way too.
  • The end date cannot fall before the start date, and the dialog will not save until that is fixed.
  • Demand is not a booking. It never appears on anyone's own capacity, and it never makes someone look busy. Only real bookings do that.

Who can do this

Setting demand requires the Resourcing Approver role — a narrower permission than the Resourcing Manager role that covers most of the grid.

This catches people out, because declaring demand does not feel like an approval. The reason is that a demand is a statement rather than a proposal: saying this project needs two developers commits the plan to a requirement immediately, with no draft stage in between and nothing for anyone to confirm later. It is therefore held to the same permission as confirming a booking. Proposing and committing explains the split.

This changed recently. Declaring demand used to come with the Resourcing Manager role. If you have been setting demand and find you can no longer save it, that is why — ask whoever administers your Flowtly account for the Resourcing Approver role. Administrators already hold it.

Withdrawing demand needs the Approver role as well, and so does raising or lowering the number of people, for the same reason: retiring a requirement or changing its size is as much a commitment as declaring one.

Moving a demand's period does not. Changing only Needed from and Needed until, leaving People needed as it is, adjusts a requirement that has already been declared rather than declaring or retiring one — so a Resourcing Manager can still do it. This is worth knowing, because re-periodising is the common edit when a project slips.

The dialog works this out from what you have actually typed, not from the role alone. It opens for anyone who can reach the grid, and Save demand stays available while your change is one you are allowed to make; it greys out, with an explanation, only once the values in front of you add up to a change that needs approval. So you find out before you commit to the edit rather than after.

If a save is refused, nothing is half-written. The check runs before any part of the change is sent, so a role's demand is never left partly rewritten — you get the message and the demand stays exactly as it was.

Reading the grid needs nothing beyond the Resourcing Manager role that gets you onto the page.

Example use cases

  • Declare that a project needs two backend developers from September, months before either of them is hired.
  • Turn a role that was quietly reading as under-covered into an accurate half-time role, and clear a false gap off the plan.
  • Raise a role from one person to two after a scope change, and see immediately which weeks are now short.
  • Withdraw the demand on a role a client cancelled, without disturbing the people still finishing their work on it.
  • Declare demand for a whole quarter, then filter to Open roles only to hand the result to recruitment as a brief.

Connection map

Derived fromPart ofRefers toFulfilsUses upPlanned vs actual
Documented hereDocumented elsewhere
job-size sizes capacity. project needs role. role drawn from position. role declares demand. booking fills role. booking books person. absence reduces capacity. booking consumes capacity. bench derived from capacity. booking planned vs actual time-entry.sizesneedsdrawn fromdeclaresfillsbooksreducesconsumesderived fromplanned vs actualJJob Size — The employment capacity an agreement commits to, in hours and minutes per week. The FTE percentage is calculated from it rather than entered: someone whose hours per week equal their job size is full-time.Job SizeCCapacity — A person's contracted week, less absence. Bookings are measured against their own contracted week, so 20 hours fills 83% of a 0.6 FTE and not 50%.CapacityPProject — The core organizational unit for a business initiative, client engagement or internal work. Everything tracked — time, cost, invoicing, profitability — hangs off one.ProjectRRole — One job to be done on a project. It may be open, partly filled, filled or over-filled, and it exists whether or not anyone is booked on it.RolePPosition — The catalogue of job titles a project role is drawn from.PositionDDemand — What a role needs, stated apart from who is doing it. Stored as one slot per full-time person, so 2.5 people is three slots. A role with none declared is treated as one full-time person.DemandBBooking — One person committed to one role for a stretch of weeks, at a percentage of their time. A booking is a plan, not a record of work done.BookingPPerson — An employee. The central record the rest of the workforce data hangs off — profile, documents, leave, benefits, rates.PersonAAbsence — Approved time off. It removes hours from a person's week before any booking is counted against it.AbsenceTThe bench — Everyone with room left in the period on screen, most free first. Derived from capacity on every period change; never a list anyone maintains.The benchTTime entry — What actually happened — work time logged against a project.Time entry