Percentages, demand rows, mid-flight changes, and ending versus deleting.
An allocation says that a person is committed to an engagement, at some percentage of their time, over a date range. It is the record that connects your people to your client work, and it drives capacity, forward planning, and whether someone is permitted to log time at all.
A person, an engagement, a role and seniority, a percentage of their time, and a start and end date.
The percentage is the part people get wrong. Fifty percent does not mean half the working day, it means half of that person's capacity is committed here, which is a planning figure rather than a schedule. Someone at 50 percent on two engagements is fully booked, and a third assignment at any percentage is an overcommitment regardless of how the calendar looks.
You can create an allocation with no assignee, describing the role, seniority, and percentage you need over a period.
This is more useful than it first appears, and it is the mechanism that turns resourcing from a reactive scramble into something you can see coming. A demand row is a commitment your firm has made without yet naming who fills it. Two of them overlapping in the same quarter is a hiring signal you can act on in month one rather than discovering in month three.
Firms that skip this end up with resource plans that only show what is already solved, which is exactly the information you least need.
When someone's commitment changes, set the new percentage from the date it takes effect. The allocation splits at that boundary rather than being overwritten, so the previous figure stays on record for the period it applied to.
That is worth understanding rather than treating as a detail. If changing an allocation simply overwrote the old value, your history would silently rewrite itself every time somebody moved, and you could never answer what the plan looked like in September. Most firms cannot answer that question, and this is why.
Ending caps the allocation at a date. The record stays, the commitment stops, and everything logged against it during its life remains intact.
Use this when someone rolls off. It is the normal operation and it is almost always what you want.
Deletion is destructive and removes the record entirely. It is for rows created in error, typically an unassigned demand row you no longer need or a duplicate.
Deletion is refused if it would orphan logged time. If a person has hours against that engagement, the allocation that permitted them has to stay, because time entries with no allocation behind them are a data integrity problem, not a tidier plan.
The rule in one line: if the work happened, end the allocation. Only delete rows describing work that never happened.
The most expensive habit in professional services, and it is a resourcing decision rather than a system one.
The pattern is familiar. You win the engagement, allocate four people from Monday, and Monday arrives without client VPN credentials. Those people are on your payroll and not on the client's invoice, and nothing in the resource plan shows it, because everyone is correctly allocated to a paying engagement.
Allocate when work can actually start. If the start date is uncertain, a demand row holds the capacity without pretending the work has begun.
One thing to know about how allocation views behave, because it causes real planning mistakes.
The current allocations view is point in time. It shows what is true as of today and does not surface allocations that start in the future. Someone who looks free this week may already be committed from the first of next month.
For any question about availability, use the view that includes past, current, and future commitments on an engagement, or the capacity search that takes a date window. Planning against a today-only view is how you promise a client someone who is already booked.
Can someone be allocated above 100 percent? The system will let you record it. Whether your firm should is a management question, and a sustained overallocation is usually a sign of a demand row nobody created.
Who can edit allocations? Project managers, unit managers, and admins.
Does an allocation have to exist before someone logs time? Yes. Time entry writes are refused if the person's allocation does not cover the engagement and date.
Tell us what you need. We will point you to the answer or write the article.
