Utilisation reporting for professional services on Dynamics 365

Utilisation is the one number every professional services firm watches, and the one number no two firms define the same way. Dynamics 365 Project Operations captures everything needed to calculate it — approved time, bookings, resource capacity — but it does not ship a report that matches any particular firm's definition, and the built-in utilisation view uses one definition that finance may not accept. This guide is about getting to a utilisation number the partners trust. For the wider fit see Dynamics 365 for professional services.

Settle the definition before touching Power BI

Utilisation is hours in the numerator divided by hours in the denominator. The fights are all about which hours.

Numerator choices. Billable hours only (chargeable utilisation), or billable plus internal project hours such as pre-sales and R&D (productive utilisation). Most firms report both and manage to chargeable.

Denominator choices. Calendar working hours (every weekday, eight hours), available hours (calendar minus approved leave and public holidays), or contracted hours for part-timers. Calendar-hours utilisation is lower and punishes people for taking holiday; available-hours utilisation is what delivery managers want. Finance often wants calendar hours because it ties to cost. Pick one as the headline and publish the other as a secondary measure, but do not let two teams present two numbers as "utilisation" to the board.

Approved versus submitted. Time that is submitted but not approved is real work but not yet billable. Report on approved time for the headline and show the unapproved backlog as its own number; a large backlog is a management problem, not a utilisation problem.

Write these decisions down. The Power BI model implements them, and every argument about a consultant's number goes back to the document.

Where the data lives

In Project Operations on Dataverse:

• Time entries hold actual hours by resource, project, task, date, and billing type, with an approval status. This is the numerator.
• Bookable resources carry the work-hours calendar that defines capacity, and a target utilisation percentage per resource. This is the denominator.
• Bookings (hard and soft) against projects and tasks are the forward-looking view — forecast utilisation, as opposed to actual.
• Resource assignments on project tasks are the plan; they matter for forecasting but should not feed actual utilisation.
• Leave is not a first-class Project Operations concept. Most firms model it as bookings against an internal "absence" project, or pull it from Dynamics 365 Human Resources or the HR system. This is the step most often skipped, and it is the reason available-hours utilisation is wrong in so many first reports.

The resource utilisation view on the schedule board calculates utilisation from bookings against calendar capacity, colour-coded against each resource's target. It is a good resourcing tool. It is not an actuals report, and it uses bookings, so a consultant booked at full time who logged half the hours still shows as fully utilised. Use it for forward planning; do not put it in front of finance as the utilisation number.

Building the report

Power BI over Dataverse is the standard path — either the Dataverse connector directly, or Azure Synapse Link or Fabric for larger firms. The model needs a date table, a resource dimension with cost centre and practice from the bookable resource, a capacity fact built from the work-hours calendar (expanding the calendar into hours per day is the fiddly part), and the time-entry fact filtered to approved status.

Measures that earn their place:

• Chargeable and productive utilisation, actual, by resource, practice, and period.
• Forecast utilisation from hard bookings for the next twelve weeks, so resourcing can act before the actual number drops.
• Unapproved time backlog in hours and days-old.
• Bench: resources with forecast utilisation below a threshold in the next four weeks.

A firm that also runs Project Operations with Finance and Operations for accounting can build the same measures over the project hour transactions in F&O; the definitions are the same, the tables differ, and mixing the two sources in one model creates reconciliation work with no benefit.

The traps

Contractors. Subcontracted resources appear as bookable resources of type Contact or Account and log time the same way. Including them in firm-wide utilisation flatters or distorts the number depending on how they are used. Report them separately.

Partial approval and rejected time. Rejected entries that are resubmitted can be double-counted if the model does not filter on the current status. Filter on status, not on the approval record.

Overtime. A consultant who logs ten hours against an eight-hour calendar day is at 125 percent utilisation. Decide whether to cap at capacity. Most firms do not cap the individual number but cap the aggregate reported to the board, and say so.

Calendar drift. Resources whose work-hours calendar was never updated after a change to part-time hours produce wrong capacity forever. Put a quarterly check of calendars against HR data into the run book.

Projects with no billing type. Time on a task whose project or contract line has no billing setup is neither billable nor non-billable and drops out of a naive numerator. Make it show as an exception.

Business Central firms

Firms running projects in Business Central have time sheets, resource capacity, and resource ledger entries, which support a simpler utilisation calculation. The capacity setup is more basic and there is no bookings concept for forecast utilisation. A Power BI model over resource ledger entries and resource capacity entries gives actual utilisation; forecast requires a planning tool or a spreadsheet. For a firm of a few dozen consultants that is fine; for a firm that needs to see the bench four weeks out, it is the argument for Project Operations.

Using the number

Utilisation is a lagging indicator of resourcing decisions made weeks earlier. The report is useful only if forecast utilisation from bookings is reviewed weekly by the people who assign work. A beautiful actuals dashboard reviewed monthly changes nothing.