Resource Requests in Jira: How to Staff Projects Across Teams Without the Spreadsheet Chaos

In any organization running more than a couple of projects at once, the hardest part of delivery isn't tracking tasks — Jira already does that well. The hard part is the layer above the tasks: deciding who works on what, when, and for how long, when every project is competing for the same specialist teams.

That negotiation — "I need a senior backend engineer at 50% for three weeks in March" — usually happens in spreadsheets, Slack threads, and meetings that should have been an email. Nothing is tracked, commitments are vague, and nobody notices an overload until the deadline is already slipping.

This guide explains how to handle that coordination as a structured resource request workflow inside Jira itself, instead of outside it.

What is a resource request (and why Jira doesn't have one natively)

A resource request is a formal ask from a project for capacity from a team: a role, an amount of time, over a date range. Think of it as a ticket — but instead of tracking work, it tracks the commitment of people to that work.

Native Jira has no concept of this. A Jira assignment is binary (a user is on an issue or not) and instantaneous (it says nothing about how much of that person's time you're claiming, or for which weeks). Even Jira Premium's Plans only lets you reason about capacity at the team level, after the fact — not negotiate it up front between a Project Manager and a Team Manager.

That gap is exactly where coordination breaks down at scale:

• Project Managers (and limited Requesters with the Jira Request resources permission) can't see whether the people they need are actually available before they commit to a date.
• Team Managers get asked for the same person by three projects and have no single place to weigh those asks.
• PMOs have no rollup of "demand we've raised" vs "capacity we've actually secured."

The resource request lifecycle

The fix isn't another spreadsheet — it's giving the request a state machine, so everyone can see exactly where each ask stands. A complete lifecycle looks like this:

1. Draft — the Project Manager or Requester sketches the need (role, hours or percentage, date range) on a timeline.
2. Submitted — the request is sent to the owning Team Manager.
3. In review — the Team Manager evaluates it against their team's real capacity.
4. Accepted (fully or partially) — capacity is allocated. Partial allocation matters: a TM can grant 60% of what was asked, and the system tracks the gap.
5. Rejected — with a reason, so the PM can re-plan instead of guessing.
6. Closed / Cancelled — the request is resolved or withdrawn, but stays in the history for audit.

The point of formalizing this isn't bureaucracy. It's that a request with a status can't get silently lost, and the difference between "what we asked for" and "what we got" becomes a number you can act on, not a feeling.

How to run cross-team resource requests in Jira

Here's the practical workflow, using Resource Management for Jira — a Forge-native app that adds this coordination layer directly inside Jira.

1. Set up your teams and real calendars

Before you can allocate people, the system needs to know your actual capacity. Define your team structure (with an RBS hierarchy and scoped Team Managers, so each manager only sees their own teams), then set effective calendars per person — working patterns, holidays, part-time schedules, and exceptions. This is what makes capacity true instead of a flat "40 hours = available" assumption.

tip

Get the calendars right first. Every fulfillment number and overload warning downstream is only as accurate as the capacity model underneath it.

2. Plan the request on a timeline

As a Project Manager (or a Requester with the Jira Request resources permission on that project), create the request directly on an interactive timeline: pick the role, the allocation (as a percentage or hours), and the period. Because you're planning visually against real calendars, you immediately see context — not just "is this person free," but "what else are they already committed to in those weeks." Requesters only see and manage their own requests; full Project Managers see all requests on managed projects.

3. Let the Team Manager allocate against real capacity

The Team Manager reviews incoming requests with full visibility into each resource's effective and remaining capacity. They can accept in full, allocate partially, or reject with a reason. Overloads are flagged in real time, so a manager can't accidentally commit someone to 130% without seeing it.

4. Turn an accepted request into actual Jira work

This is the step that keeps the planning layer connected to reality: when a request is accepted, you get one-click creation of the corresponding Jira task, with the assignee and watchers kept in sync with the request. No re-keying, no drift between "the plan" and "what's in the board."

5. Track fulfillment, not just intent

Every request carries an automatic summary: requested vs allocated hours, and a fulfillment percentage. Across a portfolio, that rolls up into one honest picture — how much demand you raised, how much capacity you actually secured, and where the gaps are before they turn into missed dates.

All requests, one organization: the portfolio view

The per-project view answers "is this project staffed?". The question above it — "what is the organization's total demand, and can the workforce actually absorb it?" — is where spreadsheets die. When every PM tracks their own asks in their own sheet, the PMO never sees total demand; the industry calls that shadow demand, and its predictable end is structural over-commitment.

Professional practice closes the loop with three mechanisms: standardization (one request format, so the data is machine-readable), centralization (one system of record instead of per-PM spreadsheets), and automated aggregation (project → team → portfolio rollups, with a flag the moment a total exceeds the team's capacity).

That's the design of the Requests surface in Resource Management for Jira:

• All resource requests across the organization in one view, with their lifecycle state — submitted, in review, accepted (fully or partially), rejected, closed. The Project Manager sees all requests on their managed projects; the instance admin — the portfolio governor — has global visibility, which is what makes the org-wide book of demand auditable.
• A request board, by state. Industry practice standardizes the states a demand object moves through — submitted → under review → capacity check → approved/pending allocation → allocated → rejected/deferred. The app's lifecycle (New → Submitted → Resource Assigned → Review → Accepted / Rejected) is that model, with the extra discipline of a reason on every rejection and closed requests that stay in history for audit.
• The portfolio priority rule. When two projects want the same ten hours of the same specialist, the decision comes from the portfolio priority list — which project outranks which — not from who asked first.
• Fulfillment at org scale. The per-request fulfillment percentage rolls up into the org-level answer: demand raised vs capacity secured, with the gap as a number — per team, per role, per period.
• The high-density timeline. For large portfolios, the compact timeline layout compares dozens of resources against multiple project demands on one screen — which is how a Team Manager spots a portfolio-wide bottleneck at a glance instead of request by request.

tip

A request without a status can get lost; a status without a reason can get argued. Both disciplines are why the lifecycle carries a reason on rejection and keeps closed requests in history.

This is the difference between a coordination feature and a governance function: the PMO sees the whole book of demand, and every number on it traces back to a calendar, a request, or a worklog.

From plan to actuals: closing the loop

A staffed plan is only half the story. The other half is whether reality matches it. Because the app reads Jira worklogs as the source of truth for actual time logged, you can compare three things on one timeline:

• Demand — what projects asked for
• Allocated — what teams committed
• Actuals — what was actually logged

That plan-vs-actual variance is what lets a PMO catch drift early — a team converting demand into allocations too slowly, or actuals diverging from the baseline — instead of finding out at the steering committee.

Keeping it native: where your data lives matters

One thing worth calling out, because it's easy to overlook until security review: many resource-planning tools pull your project, people, and worklog data out of Jira and onto the vendor's own servers.

Resource Management for Jira runs on Atlassian Forge, which means it operates inside the Atlassian environment — your data stays within Atlassian's infrastructure and isn't copied to an external server. For anyone whose org has data-residency or vendor-risk requirements, that "runs on Atlassian" property turns a procurement headache into a non-issue.

FAQ

Can I assign people to projects in Jira without a resource request? Yes — native Jira assignment works fine for "who owns this issue." Resource requests solve a different problem: negotiating how much of a person's time a project gets, across teams, before the work is assigned.

Does this work for part-time or contractor schedules? Yes. Capacity is calculated from per-person effective calendars, so part-time patterns, holidays, and schedule exceptions are reflected in true availability rather than a flat assumption.

What happens to a request if the person becomes unavailable? Because allocations are tied to calendars and the request stays a tracked object, availability changes (an approved time-off request, for example) surface against the plan instead of silently breaking it.

Do I need Jira Premium for this? No. The resource request workflow is added by the app and doesn't depend on Jira's Premium Plans feature.

Can the PMO see all resource requests across the organization in one place? Yes. The Requests view shows every request with its lifecycle state — submitted, in review, accepted (fully or partially), rejected, closed — across the managed scope, with the instance admin holding global visibility. Demand raised vs capacity secured rolls up org-wide instead of living in each PM's spreadsheet.

Next step

If cross-team staffing is where your delivery currently gets stuck, the fastest way to feel the difference is to model one real project's demand as resource requests and watch the fulfillment number do the talking.

See how it works on the Resource Management for Jira product page, or book a walkthrough.