Requesting and approving staffing

Flowtly Editorial Team4 minUpdated

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 can add a short note explaining why. The project field offers main projects only, because people are allocated on the main project rather than on its sub-projects.
  • 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.
  • Read only — someone with the Resourcing viewer role sees every request, its history and, for a declined one, the reason given, but cannot request, approve or decline. See Resourcing for everything the role covers.

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%."

Leave in the requested period. When the person has approved leave during the period asked for, a warning above the card's actions says so, naming either the whole period or the number of working days affected. It warns and does not block: Approve and the lower-share approval stay available, so the approver decides whether the booking still makes sense. Someone with read-only access sees the warning too.

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.

When an approved booking includes working days that none of the person's agreements covers, the booking is saved and a warning says how many such days there are, with a link to the person's agreements. It is the same warning a direct booking gives; see The bench and draft bookings.

If the booking changed after you opened the list, approving does not overwrite that change. The card says someone else changed the allocation after you opened it and that your change was not saved, and the list reloads with the current values. Look at the request again and approve it once they show.

Example use cases

  • Proposing a person for a role: Request a person for a project role with a share, a period and a short note, without committing the booking.
  • Approving a clean request: Confirm a request that shows free capacity across the whole period and turn it into a booking.
  • Approving at a lower share: Accept the suggested smaller share when the requested one would put someone over capacity.
  • Declining a request: Say no to a request so the requester can propose something different.

Related tutorials

Related terms