Resourcing

Resourcing answers a question that time tracking cannot: not where did the hours go, but who is going to do the work that is already sold. It shows planned capacity week by week, so gaps and double-bookings surface while there is still time to act on them.

Where Time Tracking records what has already happened, Resourcing is forward-looking. It plans commitments; it does not report on them.

Two views of the same plan

The same bookings can be read from either end, and the tabs above the grid switch between them:

Projects — organised by work. Is what we sold covered, and where is the gap? This is where bookings are made and confirmed.
People — organised by the team. How full is everyone, who has room, and who is booked past their week? Everyone with a contract has a row, whether or not anything is booked on them — except anyone excluded from project assignment, who is hidden unless you choose to show them (see Narrowing the grid below).

A third tab, Requests, is where staffing gets proposed and approved rather than booked directly — see that page for how to read and act on one. A fourth tab, Actuals, looks the other way: it sets the plan against the hours actually reported in time tracking, so you can see whether the plan held.

A Quick overview tab gives the whole team at a glance. It is read-only and shows the same plan as People, in one of two ways, chosen with the Weeks / Days switch above the grid:

Weeks shows one row per person and one column per week for the next 13 weeks, each cell a meter of how full that week is against the person's capacity. Each week's heading names the week and its first and last day, for example W30, 20 Jul - 26 Jul. On a phone each person is a card with their average and peak load, the weeks over capacity and the hours still free.
Days shows one week, Monday to Sunday, with a bar for each allocation, labelled with its project and drawn in the project's colour. Drafts and requested bookings are dashed, as on the meters, and leave is a bar of its own. Allocations that overlap are stacked in the person's row. Previous, Today and Next move a week at a time. On a narrow screen each person is a card listing the week's bars.

Point at a cell or a bar, or move to it with the keyboard, to see its figures: a bar gives its share, its dates and whether it is confirmed. A person's loose links appear under their name.

The Projects tab itself has two layouts. Capacity is the coverage grid described below. Assignments lists one row per person on each role, with their hours day by day or week by week over any range you choose.

What the projects view shows

The grid is organised by work rather than by person. Every project opens into the roles it needs, and every role opens into the people booked on it:

Project — a summary of how well the whole project is covered.
Role — one job to be done on that project, drawn from your Positions list. A role may be filled, partly filled, over-filled, or completely open. You say how many people a role needs in its demand, whether or not anyone is on it yet.
Person — an individual booking, shown when a role is expanded.

Each column is a week, and each cell is a small bar showing how much of that week's demand is covered. Capacity by project explains how to read those bars and where the percentages come from.

Select any cell and a panel opens explaining that particular number — the roles behind a project's total, the people behind a role's coverage, or everything else a person is booked on that week. See The cell drill-down.

Along the bottom of the projects view sits the bench — the people who still have room in the period on screen. Drag someone from the bench onto a role, in the column where you need them, to sketch a booking without committing to it. Bookings made this way stay reversible: a draft can be confirmed, and a confirmation can be undone. See The bench and draft bookings.

Or plan directly, without a staffing request

Dragging from the bench starts from a gap: there has to be a role on the project to drop someone onto. Often you already know who is going on a project and on which days, and that is the other way in.

Add a person books someone straight onto a project. There is no staffing request to raise first, the project does not need any roles yet, and a role is optional — something to record when it is useful, not a prerequisite. Then you type hours on the days you choose: the days need not run end to end, so Tuesday and Wednesday this week and four days next week is a plan, and the days you leave out stay empty rather than being filled in for you. An edit reaches only the person and the days you changed; the rest of the project, and the rest of that person's week, is left as it was. The bench and draft bookings walks through the picker and the day editor.

Add a person can also put someone on a project with no hours at all, as a loose link: for someone who helps a few hours a month, or who splits their days between projects. A loose link adds nothing to capacity, the bench or coverage, and never makes a project look understaffed. See The bench and draft bookings.

Once a plan exists, Move bookings… on a person's cell shifts it by whole weeks. Each day keeps its weekday and its hours, and the gaps move with it rather than closing up. See The cell drill-down.

Neither path replaces the other. Declaring a role's demand and approving a staffing request work exactly as they did, and the Requests and Actuals tabs are unchanged — an organisation that plans through roles and requests can carry on doing only that. The direct route is for the projects where the answer is already known, and the two produce the same kind of booking: a draft until an approver confirms it.

Choosing the period

The period controls and the filters share one band above the grid, with the period at its head. A period is one more way of narrowing the same plan, so it sits with the other ways rather than in a header strip of its own.

The zoom names how much time is on screen, and it is the same on the Projects and the People view: 1 week, 9 weeks and 13 weeks.
- 1 week shows one week, Monday to Sunday, a day at a time.
- 9 weeks shows nine weeks, one column per week.
- 13 weeks shows thirteen weeks in seven fortnight columns.
Switching between Projects and People keeps the zoom and the dates. A week opened up by day on one view is the same week, by day, on the other. See Capacity by person.
Previous and Next move the window by one week, at every zoom level. This is deliberate: a plan is easier to read when it slides rather than jumps.
Today returns to the current week, and Jump to moves the start to the first Monday of a chosen month without changing the range length.

The heading above the grid always names the exact range on screen, for example 20 Jul – 20 Sep 2026. On first opening the Projects view, if nothing is booked around today, Resourcing moves once to the earliest period that does contain bookings, so the page never opens on an empty grid. After that, the view stays where you put it. The People view opens on the current week.

Narrowing the grid

The filter pills sit on the same band, after the period controls.

Roles offers All roles and Open roles only. Open roles only keeps the projects that have a vacancy somewhere in the period on screen — the fastest way to turn a full plan into a short hiring or reassignment list. On the People view it leaves only the open-role rows: every person disappears, because a person row is staffed by definition.

Project narrows the Projects view to one project, listing every project in the period by name. It composes with the role filter rather than replacing it, so Open roles only plus a project gives you that project's vacancies.

Department narrows People, Projects (in both layouts), Quick overview and Requests to the people of one department, and the bench follows it. Your choice is remembered in your browser for this organisation, so it stays set as you move between tabs and from one visit to the next. Open roles belong to no department and stay visible. On Projects only the person rows are narrowed: a role's and a project's coverage still describe the whole role.

Excluded concerns people marked as excluded from project assignment. They are Hidden by default: their bookings and loose links leave every row, count and total, and they are not offered when adding a person or requesting staffing. Choose Shown to bring them back onto the grid. The pill appears only when someone in the organisation is excluded, and the bench never lists them.

The People tab adds a people filter of its own; see Capacity by person.

Each active choice adds a chip below the band. Removing a chip clears only its own filter, and Clear all removes them together. If the filters leave nothing on screen you get a short No results line with a clear-filters link, rather than the "nothing here yet" state — there is data, it is just hidden.

Who can use it

Resourcing requires the Resourcing module on your subscription and one of the Resourcing roles — Resourcing manager, Resourcing approver or Resourcing viewer, described below. People without the module and a role do not see the entry in the menu.

People and Projects have read-only phone cards. People cards show planned hours, capacity, free hours and separate proposed hours. Projects cards show confirmed coverage, declared demand, open demand and separate proposed hours. Long names wrap, and the totals describe the matching cards.

Dates, range controls and shared links remain available. Clear filters removes role, project and capacity filters while keeping the period. If the allocation download fails or is incomplete, capacity totals are withheld so a partial plan cannot look complete.

Changing bookings and the Requests workflow need a larger screen. Actuals keeps its phone layout for reading delivered work. See Actuals — plan vs reported.

Proposing and committing are separate permissions

Planning is split into two privileges, because sketching an option and committing the company to it are different decisions — and so that proposing a booking and approving it can be different people:

Resourcing manager — proposes. Creates drafts, both by dragging from the bench and by adding a person directly to a project, extends and shortens them, changes how much of someone's time they take, moves drafts to other weeks, deletes drafts, and imports allocations. This is the everyday planning role.
Resourcing approver — commits. Everything a Resourcing manager can do, plus confirming a draft into counted coverage, un-confirming it again, deleting a confirmed booking, changing or moving a day that is already confirmed, and declaring a role's demand — which is how an open role appears on a project in the first place.

Approver is an addition rather than a swap, so an approver can still plan. Administrators hold both and are unaffected.

The Approver role has to be assigned by hand. It is deliberately not part of any permission group by default — if it were granted automatically to everyone who can plan, the separation would not exist. In a new organisation it is a setup step worth doing early: until at least one person holds it, nobody there can confirm a booking or declare what a role needs. Assign it from Permissions.

If your organisation was already using Resourcing, nothing changes for you. Confirming used to come with the Resourcing manager role, and is now the separate Approver role — but everyone who could confirm beforehand was granted it, so the people staffing your projects carry on exactly as they did. The separation is available rather than imposed: an administrator can take the Approver role off a planner deliberately, if you want proposing and committing to be different people.

If you do find Confirm and Un-confirm greyed out, the arrows that change a confirmed row's period greyed out, or a role's demand refusing to save, you need the Resourcing approver role — ask whoever administers your Flowtly account to grant it.

Those controls stay visible rather than disappearing, and say on hover what they need. Finding a step greyed out with a reason is a question you can act on; finding it gone looks like a fault.

Read-only access: the Resourcing viewer role

Not everyone who needs to see the staffing plan should be able to change it. A delivery lead following a project, a department head checking who is assigned where, or a sales manager asking whether a start date is realistic can be given Resourcing viewer instead of a planning role.

A Resourcing viewer can see:

the schedule on both the Projects and People views, including opening a week by day;
the Requests tab, with each request's history and the reason given whenever one was declined.

A Resourcing viewer cannot:

change anything — book, move, extend, confirm, decline or delete a booking, approve or decline a request, or declare what a role needs. These controls are simply not shown to a viewer, rather than shown greyed out, because there is nothing a viewer could ask for on each row;
see the bench — the list of who is free — because that is a planning tool;
see Actuals, and with it any revenue, cost or margin figure.

Resourcing viewer is granted person by person and is not part of any permission group by default. Assign it from Permissions. Administrators already have it.

The Resourcing role decides what you can do on the page, not whose rows you can see. A viewer, exactly like a manager, also needs the usual permissions to view people and projects to see the whole grid.

Nothing changes for anyone who already plans: the Resourcing manager and Resourcing approver roles keep the full access described above.

What gets recorded

Every change a person makes to a booking is recorded — who made it and when — across creating, confirming, un-confirming, changing the dates or the percentage, and deleting. This record is kept indefinitely.

Bookings that arrive from an imported plan are the exception. They are mirrored from that plan rather than authored here, and re-mirrored whenever it is applied again, so the import's own report is their record instead.

It matters most for deletion. Removing a draft is permanent: the booking itself is gone rather than hidden, and the record of the change is the only remaining trace that it ever existed.

The record is not something you can browse from the Resourcing page. If you need to establish who changed a booking, ask your Flowtly administrator.

Example use cases

Declare that a project needs two developers from September, and watch the gap appear on the plan until it is filled.
Spot next month's understaffed projects before the client does, and fill them from the bench.
Find the roles that are still open across the quarter, and turn them into a recruitment brief.
Check whether a proposed new engagement can be staffed at all before committing to a start date.
Catch a person booked past full capacity across two projects while there is still time to rebalance.
Switch to the People view to see who has room next month, without keeping a bench list anywhere.
Check on the People view that a part-timer is not booked as though they worked a full week.
Open a project cell reading 50% and find out in one line whether that is two half-staffed roles or one unfilled one.
Open a conflicted week into days to see which days the leave and the booking actually collide on.
Sketch several staffing options as drafts, compare them on the grid, and confirm only the one that works.
Put the person you have already promised onto a project for a handful of days, without first declaring a role for them to fill.
Slip a planned stretch two weeks later when a client moves a start date, keeping the same weekdays and the same gaps.