Request staffing and approve the request

Ask for a person on a project, read the verdict before you decide, and settle it: approve, approve at a lower share or decline with a reason.

ResourcingIntermediate8 minutes

Topics:Projects and time tracking

Before you start

Not everyone who plans work can book it. A staffing request is the lighter route: someone with the Resourcing manager permission proposes, and a Resourcing approver decides. Until the decision, the request does not count against anyone's capacity.

The request queue has its own view, Requests, at /resourcing/requests. It collects requests from every project, so the approver has one place to review rather than one per project.

This tutorial walks through both sides: first submitting a request, then reviewing it. Each step names the fields and buttons you see in the app.

What you will have at the end

Every staffing request in the queue is approved, approved at a lower share, or declined with a reason.

What you need

  • The Resourcing manager permission to submit a request, or Resourcing approver to decide it.
  • The project, the person and the share of their time you want to request.

Try it in the demo

Click through these screens with sample data first. No account needed.

Open the live demo

Step-by-step

Complete the flow

  1. 1

    Ask for a person

    In the Resourcing header, click Request staffing. The panel has six fields: Project, Person, Role, Weekly share (%), the period and Why this is needed. The period is preset to the one open on the grid, so if you are planning September you do not type September a second time. The approver reads the note together with the request. Finish with Send request.

    Tips

    • A request is a proposal, not a booking. Nothing is taken until someone with approval rights confirms it, just like a draft on the grid.
    • Role is required here, unlike in Add a person, where it is optional. The card the approver sees describes the request as a project and a position. Without a role, only the project would be left.
    • The share is a percentage of the week, from 1 to 125%. Flowtly rejects a value outside that range in the field straight away, and shows the conversion next to the number as 60% = 24 h/week.
  2. 2

    Review the queue in the Requests view

    Switch the view to Requests. Each item has a status of Pending or Conflicts, the project name with the position, Period, Share and Note, and below that a requested by caption with the time. The header sums up the queue, for example 3 pending · oldest 5 days. That is the only number that tells you whether someone has been waiting too long.

    Tips

    • An empty queue shows the message No requests awaiting approval. It does not mean nobody is planning. Requests only land here when someone requests staffing. Staffing added directly on the grid skips this queue.
    • The Conflicts status does not block approval. It only says that in some week the request will not fit the person's capacity. You decide what to do about it in the next step.
    • Someone with the Resourcing viewer permission sees the queue, the decline reasons and the history, but cannot approve or decline.
  3. 3

    Read the verdict before you approve

    The request shows what will happen if you approve it, calculated for this person and this period, not estimated. No conflict is a sentence saying the person has free capacity across the whole period. A conflict reads differently: Flowtly tells you how high the load will go, and in how many of the requested weeks. If a smaller share would fix it, Flowtly suggests a specific value in the sentence Approve at X% instead.

    Tips

    • Read the strip of weeks under the verdict cell by cell. Each week shows the load after approval and is flagged when it is overallocated.
    • The verdict covers the period in the request. Besides approving at a smaller share or declining, the third way out is to ask for a shorter period.
  4. 4

    Approve, in full or at a smaller share

    Approve as requested confirms what was asked for. When the verdict suggests a lower value, the second button carries it in its label, for example Approve at 40%, and one click turns the request into a confirmed allocation at that share. From then on the staffing counts against the person's capacity and shows on the grid and in the Actuals view.

    Tips

    • If the approval is refused, trying again changes nothing: the request cannot be accepted as it stands, most often because it would exceed capacity in some week. Approve at a smaller share or ask for a shorter period.
    • The decision can be reversed. On the grid, the same allocation can be turned back into a draft with Un-confirm. That also needs the approver permission.
  5. 5

    Decline with a reason

    Decline opens the Decline request dialog with a Reason (optional) field. The reason is optional for Flowtly, but not for the person who asked. It is stored with the request and stays in the history, so everyone can see why the plan did not change.

    Tips

    • Declining removes nothing from the grid. The request was never a booking, so after a decline the staffing stays as it was.
    • The shortest useful reason names the obstacle and the alternative, for example busy until 20 November, free from the 23rd. The requester can then submit a request that has a chance of going through.
  6. 6

    Check what changed

    The What changed panel records decisions in order: who submitted a request, who confirmed it, who changed an allocation, who un-confirmed it and who removed someone from the schedule. Opened from a project, it carries the project name in its title, so you read the history in the context of one project rather than the whole organisation.

    Tips

    • The history is a record of decisions, not of every change to a cell. It answers who approved this and when, which the grid alone does not show.
    • Someone with view-only access also sees the decline reasons and the history. It is a shared record, not the approver's private note.

You’re finished!

The Requests queue is reviewed: every request has been approved, in full or at a lower share, or declined with a reason that stays in the history.

Approved requests show on the grid as confirmed staffing. After a few weeks they also show in the Actuals view, which tells you how many of those hours were actually logged.