Requesting and approving staffing

Flowtly Editorial Team4 min

The Requests tab is where staffing stops being decided in chat and starts being decided on the record. A project manager requests a person for a role; someone with approval rights confirms or declines. The catch that would have made this just a slower chat — working out whether the person is already too busy — is done for the approver before they open the request.

Where Projects is where bookings are made and confirmed directly, Requests is the lighter path for anyone who can propose staffing but not commit it.

What a request is

A request is not a separate kind of record. It is an ordinary booking that has been asked for but not yet agreed to — the same person, role, share and dates you would confirm, held in a pending state until someone approves it. Approving it turns it into a confirmed booking; nothing is re-entered.

Because a request is only a proposal, it never counts toward anyone's planned capacity. It will not fill a gap on the Projects grid or push a person over their week on the People grid until it is approved.

Who can do what

  • Request — anyone who can propose bookings. They pick the person, the role, the share and the period, and add a short note explaining why.
  • Approve or decline — only someone with staffing-approval rights. This is the same permission that lets a booking be confirmed anywhere else in Resourcing, so the people who already sign off on staffing are the people who act on requests.

Reading a request

Each pending request is a card showing who was asked for, by whom, and how long ago, along with the project, role, period, weekly share and any note the requester attached. Below that, a bar for every spanned week, and a line stating what approving it would mean:

  • No conflict — a green line confirms the person has free capacity across the whole period.
  • Conflicts — a red line states the consequence in plain terms — for example, "Approving this puts Anna over capacity — up to 118% across 3 of the requested weeks." — and, where a smaller share would fix it, a second line offers it: "Approve at 25% instead to keep every week at or under 100%."

The point is that the approver decides, rather than re-deriving the numbers themselves. A conflict Flowtly can see, it shows.

Acting on a request

Up to three actions sit on each card:

  • Approve turns the pending request into a confirmed booking at the share that was asked for. When approving would still leave someone over capacity, this button reads Approve as requested instead, so choosing it is a deliberate override rather than a default click.
  • Approve at a lower share (shown only when there is a conflict with a clean fix) confirms it at the suggested percentage instead, so no one ends up over-booked.
  • Decline removes the request entirely. Use it when the answer is no; the requester can propose something different.

Approving obeys the same over-booking guard as every other confirmed booking, so an approval that would push someone past the allowed ceiling is refused just as a direct booking would be.

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