The resource hub in Project Operations

How resource management works in Dynamics 365 Project Operations — bookable resources, skills, calendars, requests, and the bookings model.

Updated 2026-08-22

For a services business, resourcing is the operational heart of the system — who's free, who has the right skills, who can travel, who's most billable, who's underutilised. Dynamics 365 Project Operations models this through the resource hub, a workspace combining resource records, requirements, requests, and bookings.

Bookable resources. A bookable resource is anyone or anything that can be scheduled. The basic types:

  • User — an employee mapped to a Dataverse user.
  • Contact — an external contractor.
  • Account — a partner organisation.
  • Equipment — physical equipment that can be assigned to projects.
  • Group — a named team treated as a unit.
  • Crew — a pre-defined multi-resource team.
  • Facility — a meeting room or location.

Each bookable resource carries:

  • Skills — what the resource can do (Architect, Project Manager, Senior Developer, Spanish-speaking, AWS-certified, etc.).
  • Role — the primary job role.
  • Cost rate — internal hourly cost.
  • Billing rate — default billable rate.
  • Calendar — working hours, holidays, time off.
  • Location — for travel-time calculation and territory matching.

Skills and proficiency. Skills are configured as a hierarchical taxonomy. Each resource's skills carry proficiency levels (1–5 or beginner-to-expert). Matching considers both presence and proficiency — a senior architect role requires Architect skill at proficiency 4+.

Resource requirements. A project task or role identifies a need — "Senior Architect for 2 weeks starting March 1st, 80% utilisation, Spanish-speaking preferred, must be in EU for travel cost". The requirement captures the specifications; the matching engine finds candidates.

The resource hub workspace. Inside Project Operations, the resource hub workspace shows:

  • Schedule board — Gantt-style view of every resource's bookings across time, draggable for changes.
  • Resource utilisation — billable vs total time per resource, with red/amber/green health indicators.
  • Open requirements — unfilled resource needs across active projects, with priority and start date.
  • Request queue — formal resource requests awaiting approval and assignment.

Resource requests and approvals. Different organisations use different resourcing flows:

  • Direct booking — project manager picks a resource and books directly.
  • Resource request workflow — project manager submits a request to a resource manager who approves and assigns.
  • Hybrid — direct for low-impact bookings, request flow for high-impact (long duration, senior resources, cross-region travel).

Workflows are configurable per organisation.

Generic resources and substitution. Early in a sales pursuit, a deal is staffed with generic resources (placeholders representing roles, not named people) so utilisation forecasting works without committing real people prematurely. When the deal closes, generics are replaced with named bookable resources.

Match-and-suggest. Project Operations uses an AI-assisted match function: given a requirement, suggest the best candidates ranked by:

  • Skill match (presence and proficiency).
  • Availability (calendar).
  • Cost (internal cost rate).
  • Past project performance.
  • Location.

The resource manager reviews suggestions and makes the final pick.

Bookings. A booking binds a resource to a project / task for a date range and capacity. Bookings have statuses (soft, hard, committed) — softs are pencilled in; hards are committed and notified.

Integration with timesheets. Once booked, the resource sees the booking in their Project Operations workspace; time entered on the booked project task posts back as actuals against the booking.

Reporting. Utilisation per resource, project, role, region; bench time (resources without bookings); pipeline coverage (do we have enough capacity for the projects we hope to win?).

Operational reality. Resource hub adoption follows resource-manager discipline. Without the resource manager actively running the hub, the system surfaces inaccurate utilisation, requests pile up, and projects start without resourcing certainty. The technology supports the discipline; it doesn't replace it.

Related guides