Connecting Power BI to Project Online - Turning Project Data Into Reporting Leaders Will Read

If your organisation runs projects through Project Online, you already know the gap I am about to describe. The project managers live in the tool, they update their schedules and resource assignments, and the data is genuinely rich. Then the PMO or the executive team wants a portfolio view across every project, and suddenly someone is manually copying status into a spreadsheet every Friday afternoon. That Friday spreadsheet is the thing we get asked to kill, and Power BI connected straight to Project Online is usually how we do it.

The good news is that the connection is well trodden and the data model behind Project Online is properly structured, which is not something you can say about every source. The less good news is that Project Online reporting has a few sharp edges that catch people out, and the tool itself now sits in an odd place in Microsoft's roadmap that is worth understanding before you build anything on it. Microsoft's Project Online connector guidance covers the mechanics. Here is what we have learned building these for clients.

How the connection actually works

Project Online exposes its data through an OData feed. In plain terms, that is a web address that hands out your project data in a structured form that Power BI can read directly. You point Power BI Desktop at that feed, authenticate with your Microsoft 365 account, and you get access to a whole set of tables: projects, tasks, resources, assignments, timesheets and more.

The mechanics are refreshingly straightforward. In Power BI Desktop you choose the OData feed as your source and paste in your Project Online reporting endpoint, which is your PWA site address with the reporting data path on the end. You sign in with an organisational account that has the right permissions, and the tables appear. From there it is standard Power BI work: shape the data, build relationships, write your measures.

Because it is OData and it is a first-party path, you are not depending on any third-party connector, and the feed reflects your live data every time it refreshes. That is a solid foundation. The catch, as always, is in the details of what that feed gives you and how much of it you actually want.

The feed gives you everything, which is the problem

The single most common mistake we see is treating the Project Online OData feed like a firehose and pointing Power BI at all of it. The feed is enormous, and if you pull every table with every field and every historical row, you end up with a slow, bloated model that takes an age to refresh and confuses everyone who opens it.

The reporting endpoint exposes a lot of entities, many of which you will never report on. Pulling the full task list for every project going back years, when the executive view only needs current project status and top-line health, is a classic case of dragging in a hundred times more data than the report needs. The refresh crawls, the file balloons, and the report is slower for no benefit.

The discipline that fixes this is boring and it works. Decide what the report needs to answer first, then pull only the tables and fields that serve those questions. Filter the data at the source where you can, so you are not shipping ten years of completed tasks into a model that only cares about live projects. This is the same principle that separates a Power BI deployment that runs quietly from one that generates a steady drip of "why is this so slow" complaints, and it is a big part of the Power BI work we do for clients.

There is also a genuine performance ceiling with OData feeds on large project portfolios. The feed was not built for pulling enormous volumes in one hit, and organisations with hundreds of active projects and deep task detail will feel it. For those, incremental refresh, so you only pull what has changed rather than everything every time, moves from nice-to-have to essential. Setting that up properly takes a bit of thought, but it is the difference between a refresh that finishes in a minute and one that times out.

The data is richer than people expect, if you model it

Once the data is in, the thing that surprises people is how much you can do with it, provided you actually model the relationships rather than dumping tables side by side.

Project Online holds the real structure of your projects: which resources are assigned to which tasks, planned versus actual work, timephased data showing how effort spreads across weeks, and custom fields your PMO has defined for things like project stage, business unit or strategic priority. Those custom fields are gold for portfolio reporting because they are how your organisation actually categorises work, and they come through the feed if you know to look for them.

Where it gets powerful is resource reporting. Executives constantly want to know who is overallocated, where the capacity crunch is coming, and whether the portfolio is even deliverable with the people available. That analysis is entirely possible from the assignment and resource data in the feed, but it needs proper modelling. You have to connect assignments to resources and to the calendar, and build measures that compare planned effort against capacity. It is not hard once you know the shape of the data, but it does not fall out of the box, and this is exactly where an hour with someone who has built it before saves you a fortnight of trial and error.

Honestly, this is where most Project Online reporting stops short. People build a nice project status grid and call it done, when the real value the executives are after is the forward-looking resource and delivery picture. That is a modelling job, not a connection job, and it is worth the extra effort.

The elephant in the room - Project Online's future

I would be doing you a disservice if I did not raise this, because it changes how you should think about any investment here. Microsoft has been steering customers toward newer project and work management tools for a while, and Project Online is not the horse they are backing for the long term. It still works, it is still supported, and plenty of organisations run it happily. But if you are building serious reporting infrastructure on top of it today, go in with your eyes open about where the platform is heading.

Practically, that does not mean avoid it. It means build your Power BI model so the logic and measures are as portable as possible, and do not over-invest in brittle, deeply Project-Online-specific plumbing that would be painful to unwind. When the time comes to move to a newer platform, a clean, well-structured Power BI model with the business logic held in measures rather than baked into a hundred fragile queries is far easier to re-point at a new source. This is the kind of forward-looking call we help clients make as part of a broader AI and data strategy rather than a one-off report build.

Getting it right

The version of Project Online reporting that actually earns its keep is not complicated, it is disciplined. Connect through the OData reporting endpoint with a proper organisational account. Pull only the tables and fields the report needs, and filter at the source rather than dragging everything in. Use incremental refresh once your portfolio gets big enough to feel the OData performance ceiling. Model the resource and assignment data properly, because that forward-looking capacity view is the whole reason executives care. And keep your business logic in portable measures so you are not painted into a corner if you move platforms later.

Do that and you replace the Friday spreadsheet with a live portfolio view that the PMO trusts and the executives actually read. Do it carelessly and you get a slow, confusing report that people quietly go back to ignoring in favour of the spreadsheet.

If you are running Project Online and still assembling your portfolio reporting by hand, or you have a Power BI model that has grown slow and unloved, that is precisely the sort of thing we sort out. Take a look at our services or get in touch and we will give you a straight assessment of what your setup needs.

For the connection steps and current requirements, Microsoft's Project Online connector documentation is the reference worth keeping open while you build.