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 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 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.

подсказка

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, 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."

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.

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.

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.