Workflows · 7 of 10

Capacity: measure the demand

Teams ask for headcount with anecdotes and get told no with numbers. The numbers they need already exist, split across two systems.

In plain terms

Workfront already knows how busy each person is. Planning adds the other half: how much work is being asked for, by whom, and how that compares with last year. Together they make a headcount case.

Mostly a Workflow job

Capacity is mostly a job for Workfront Workflow. Resource management, the workload balancer, and utilization reporting already own assignment-level capacity, with timesheets behind them. Rebuilding that in Planning gives you worse numbers with nothing underneath.

Planning’s contribution is the demand side: how much work is being asked for, by whom, in which period, and how that trend compares year over year. That is the evidence headcount conversations actually run on.

Figure 1. The two halves of a capacity conversation. Blue is demand, which Planning measures; gold is capacity, which Workfront Workflow measures.

Two halves of one case

Press Play, or select any part of the figure, to walk through the evidence one step at a time.

What the intake record type must capture

The demand side only works if intake — workflow 1 — captures these, every time.

Demand field checklist

0 of 6 added ·

Requested datecreated dateAutomatic. The period a request belongs to.
Needed bydateSeparates urgent demand from planned demand.
Request typesingle-selectThe mix: how much of the volume is design, copy, video.
Requesting teamconnectionWho is asking — the conversation changes when one team drives most of the growth.
Accepted / Declinedsingle-selectTriage status. The decline rate is evidence too.
Delivering projectconnectionAccepted requests connect to the Workfront project, which is where the hours are.

An optional Capacity record type

For a planning-level forecast, add a Capacity record type (Planning’s word for a table) with Team, Period, Available person-weeks, Committed person-weeks, and Utilization. Make Committed a summarized lookup and Utilization a formula.

Source the committed number from Workflow. Committed person-weeks must come from Workfront — as a lookup or a sync — not be typed into Planning. A typed number is an opinion; the point of this workflow is evidence.

Building the case

Compute request volume by period, type, and requesting team, and compare it with the prior year.
Pull assignment-level load from Workfront for the people in question.
Propose reassignment or push-back candidates among low-urgency accepted requests.

Hand off two things together: the demand view in Planning and the relevant Workfront utilization report.

# Demand, from Planning
  FY26 Q3: 150 accepted requests, up from 100 in FY25 Q3 (+50%)
  Design is 62% of volume, up from 48%

# Capacity, from Workfront
  Designer A at 95% of available hours
  Designer B at 60%
  Designer C at 110% — two P3 briefs are the push-back candidates

Headcount evidence: +50% accepted volume, no headcount change,
decline rate up from 4% to 11%

Don’t do this

Rebuilding the workload balancer

Assignments, hours, and leveling belong in Workfront resource management. A Planning copy has no timesheets behind it.

Typed utilization

If the committed number is typed, nobody will believe the case it makes. Pull it from Workflow.

Demand without dates

Without the requested date captured on every request, there is no year-over-year comparison — and no case.

Hiding the declines

The decline rate rising from 4% to 11% is part of the evidence. Record declines with a reason; do not delete them.

Sources

Adobe Workfront Planning documentation — terminology, request forms, automations, object limitations: Experience League article index
Planning API reference, versions 1 and 2: developer.adobe.com/wf-planning
Package contents and entitlements: Adobe Workfront product description