What are Positions and Allocations?

Positions and Allocations are the two layers Operating uses to plan work on a project — a Position defines who holds a role, and Allocations define when and how much they're planned to work.

Written By Lauri Eurén

Last updated 9 days ago

In Operating, work on a Project is organized into two layers: Positions and Allocations. A Position is a role a Person holds on a Project. An Allocation is a block of planned time assigned to that Position for a specific date range. One Position can have many Allocations.

This split is what lets you plan work accurately while preserving history — the Position records who held a role, and the Allocations record when and how much they were planned to work.

The Position: a role on a Project

A Position is an assignment of a Person to a Project, representing their role and responsibilities there. A Position can carry attributes that drive planning and financials:

  • A role, site, seniority, and skills — either as requirements (for an unfilled Position) or describing the assigned Person.

  • A billing rate — either set specifically on the Position, or inherited from the Project's rate card.

  • A Project phase — a Position can belong to a phase, which is how tracked time becomes associated with that phase (a Time entry inherits its phase from the Position it is tracked on).

A Position can be unnamed — it can exist before anyone is assigned, which is how you plan a team shape before you know who will fill each seat. When you're staffing, you pinpoint the role, site, seniority, and skills the Position needs, and Operating uses those requirements to narrow down the people who could fill it. See How to find available people for a project.

The same Person can hold multiple Positions on the same Project, even overlapping, when they play more than one role (for example, project manager and strategy consultant).

The Allocation: planned time on a Position

An Allocation is a planned piece of work, expressed as a percentage of the Person's working time over a date range — full-time, part-time, or down to a few hours on a single day. (The percentage is relative to that Person's own working hours, so 100% means a full day for them.) Allocations belong to a Position, and a single Position can have many of them — so a Person's planned involvement can rise, fall, pause, and resume over the life of a Project.

For example, a Position might have these Allocations:

  • 100% for the first two weeks

  • 50% for the following week

  • a gap (no Allocation) for two days

  • 4 hours on a single day later on

Each Allocation is either confirmed (committed work) or tentative (planned but not yet certain, such as work tied to a deal that has not closed). This distinction drives how the work shows up in capacity and financial reports.

Why the two layers matter

Because the Position is separate from its Allocations, history stays intact when plans change. When you rotate one consultant off a Project and bring another on, you end the first Person's Allocations and add a new Position for the incoming Person — the original Position and its past Allocations remain as a record of what was planned, rather than being overwritten.

This structure makes it possible to plan work accurately while preserving history — a position records who held the role, while allocations record when and how much they worked.

What a Position can describe

A Position carries a set of attributes. On an unfilled Position they read as requirements — the shape of the seat you are trying to fill. You may assign a person that doesn’t meet all of the requirements. On a filled Position they describe the seat the assigned Person occupies.

Four of these attributes drive candidate matching when you go looking for a Person:

Parameter

What it expresses

Role

The competence role the seat calls for — Developer, Designer, Project Manager.

Seniority

The seniority level within that Role.

Site

The office, region, or location the seat belongs to.

Skills

One or more specific capabilities the seat needs — React, dbt, Agile.

Groups

The organizational unit(s) the seat belongs to. One Position can be in several.

The remaining attributes matter for planning and financials, but do not affect who Operating suggests as a candidate:

  • Billing rate — either set specifically on the Position, or inherited from the Project's rate card. Note that Role, Seniority, and Site are also rate card dimensions, so setting them changes which rate the Position inherits. Read more at How does Operating decide which rate to use?

  • Project phase — a Position can belong to a phase, which is how tracked time becomes associated with that phase (a Time entry inherits its phase from the Position it is tracked on). Read more at What are project phases?

  • Note, status, and external assignee cost.

Groups on a Position

A Group is an organizational unit — a department, a team, a business unit. People, Projects, and Positions can each belong to Groups.

The important part: a Position carries its own Groups, independent of the Groups on its Project. A Project owned by Consulting can hold a Position that sits in Data & AI. And a single Position can belong to several Groups at once.

How to add a Group to a Position

You can set a Position's Groups in three places:

  • When creating a Position — open the position create form, expand the additional details, and use the Groups field.

  • When editing a Position — the same Groups field is in the position edit form.

  • Inline on the Position itself — on the Project's Team tab and in the Timeline sidebar, the Position shows its Groups as tags. Click a tag (or Add group if it has none) to add or remove Groups directly, without opening a form.

Only active Groups can be selected. If a Group is archived after being assigned, it quietly stops appearing on the Position.

Why it is worth doing

1. Better staffing suggestions. Group becomes a matching dimension when you search for a Person — Operating ranks people who belong to the Position's Group above those who don't, and gives you a one-click filter for it. See the next section.

2. Sharper reporting and filtering. The Position list has a Position group column and filter, separate from the Project group column and filter. You can also group the list by either one. So you can answer "how much of Data & AI's capacity is committed?" even when the underlying Projects belong to other units.

3. Accurate records for cross-unit work. When a Project is delivered by one unit but staffed from another, the Position records where the work actually came from, instead of everything being flattened into the Project's Group.

4. Laser-focused staffing when assigning a member of a particular team. Some organizations keep their teams unnamed for as long as possible, but might still decide that “this data management position shall be one of the Sigma Team members”. It’s then up to the Sigma Team to name that person just in time.

Not seeing the Groups field? It appears only if your workspace uses Groups. If your organization hasn't set any up, the field stays hidden.

Finding the right Person: how matching works

When you open Choose person on a Position, Operating doesn't hand you a flat alphabetical list of everyone. It reads the Position's parameters and sorts candidates into ranked groups, best fit first.

The ranking

Role and Seniority dominate. The strongest signal is matching the Position's Role and Seniority; next is matching the Role alone; last is matching neither.

Site and Group stack on top. Within each of those Role tiers, candidates are ordered by how many of the secondary dimensions they also match. So you'll see headings like:

Role, Seniority, Site & Group match
Role, Seniority, Site match
Role, Seniority, Group match
Role, Seniority match
Role, Site & Group match
Role, Site match
...
Site & Group match
Site match
Group match
Everyone else

Only the dimensions you actually set appear. If the Position has no Site, no Site heading is generated.

Skills sub-rank within every heading. If the Position lists required Skills, each heading is further split by how many of them the candidate has — Role & 2/3 skills match, then Role & 1/3 skills match, then Role. Partial matches are ranked, not discarded, so you can see the almost-fits instead of losing them.

Within the Role-only group, the most senior people come first, then alphabetically. Other groups are alphabetical.

If the Position has no Role, Site, Group, or Skills, you get a flat alphabetical list with no headings — there is nothing to match on. This is the single most useful thing to know: the more parameters you set on the Position, the more the candidate list sorts itself for you.

Who appears in the list

Only active people you are permitted to assign to that Project. The list also caps at 100 people at a time — if you're in a large organization, narrow the list with the filters below rather than scrolling.

Narrowing the list with quick filters

Above the candidate list, Operating shows a row of quick filter pills built from the Position's own parameters: its Role, its Site, its Skills, and its Groups. Ranking suggests; these pills filter. Tapping one turns that parameter into a hard requirement and removes everyone who doesn't meet it.

Two behaviors are worth knowing:

  • Skills combine with AND. Select two Skill pills and only people who have both remain.

  • Groups combine with OR. Select two Group pills and anyone in either Group remains. This is deliberate — a Position's Groups are parallel organizational axes, not a checklist.

If the Position has many required Skills, only the first few pills are shown, with a +N more link to reveal the rest.

The search box matches on a person's name and on their role names, so typing "designer" works as well as typing a name.

Reading availability

Each candidate row shows how free they are, as a percentage with a colored bar:

  • Green — more than 75% free

  • Amber — more than 50% free

  • Red — 50% free or less

The number accounts for the person's own working hours and their holidays, and the tooltip tells you which period it was measured over. That period depends on the Position:

Situation

Period measured

The Position has Allocations with fixed dates

During those Allocations

The Position has open-ended Allocations

The first four months

No Allocations, Project has estimated dates

The Project's estimated period

No Allocations, Project has an estimated start only

Four months from that start

Nothing set

The next four months

The tooltip also surfaces overlapping tentative plans — work on other Projects that isn't confirmed yet but would clash. That lets you tell a genuine conflict from a soft one before you commit someone.

A worked example

You're staffing a Position: Senior Data Engineer, Helsinki, Data & AI group, requiring Python and dbt.

Open Choose person and you might see:

Role, Seniority, Site & Group & 2/2 skills match      Aino V.
Role, Seniority, Site & Group & 1/2 skills match      Jonas L.
Role, Seniority, Group match                          Priya R.
Role & 2/2 skills match                               Tom H.
Everyone else

Aino is the obvious fit. But if she's showing 20% free in red over your Allocation period, the list has already given you the alternatives: Jonas is in the right unit and location but is missing dbt; Priya is a senior data engineer in Data & AI who sits in another office; Tom has both skills and the right role but isn't senior.

If the top groups are empty or everyone is booked, relax a parameter rather than scrolling. Tapping the Helsinki pill off widens the field to remote candidates; removing dbt from the Position's Skills opens it to people you could pair with a dbt specialist.

Practical guidance

  • Set the Position's parameters before you open Choose person. Matching reads the Position, not the search box. An empty Position gives you an unsorted list.

  • Under-specify on purpose when you want a wide net. Every parameter you add narrows the top group. If you genuinely don't care about Site, leave it blank rather than filling it in for tidiness.

  • Reach for Group when Role and Site aren't discriminating enough. In a large single-site organization, "Developer in Helsinki" may describe 200 people. "Developer in Helsinki, Data & AI" describes a team.

  • Use the pills to test trade-offs. Toggling Site or a Skill off and on is the fastest way to see what a compromise buys you in availability.

Frequently asked questions

How can I remove a person from a project? Click on the Project Position they're assigned to, and in the popover that appears, remove them as the assigned Person for the Position. The Position and its history remain.

Why don't I see the Groups field on a Position? Your workspace isn't using Groups. Once your organization sets Groups up, the field appears on the position forms and on the Position itself.

Position group or Project group — which should I filter on? Filter on Project group to ask "which unit owns this work?". Filter on Position group to ask "which unit is doing this work?". For organizations where projects are delivered across unit boundaries, Position group is usually the one you want for capacity questions.

Why is someone missing from the candidate list? Three common reasons: they're inactive, you don't have permission to assign them to that Project, or the list has hit its 100-person cap. Use the search box or the quick filters to bring them into view.

Does the Position's billing rate affect who is suggested? No. Rate, phase, note, and status play no part in matching. Only Role, Seniority, Site, Skills, and Groups do. Note though that Role, Seniority, and Site are rate card dimensions, so changing them to widen your search may also change the rate the Position inherits.

Related articles

How to find available people for a project