> For the complete documentation index, see [llms.txt](https://help.aphex.co/docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://help.aphex.co/docs/insight/insight-and-power-bi.md).

# Insight & Power BI

Project Insight and the Power BI integration work alongside each other. Project Insight brings the most common performance reports directly inside Aphex, computed server-side, updated every publication. Power BI remains the best option for deeper, plan-level analysis.

## What Project Insight covers

***

These reporting needs are now available directly in Aphex. Where the same metric also appears in Power BI, the table notes it.

<table><thead><tr><th width="273.61328125">Reporting need</th><th width="172.84375">In Project Insight</th><th>Also in Power BI?</th></tr></thead><tbody><tr><td><strong>PPC &#x26; Task Progress over time</strong></td><td>PPC Dashboard</td><td>Yes (calendar-day basis)</td></tr><tr><td><strong>PPC / Task Progress by Subcontractor &#x26; Owner</strong></td><td>PPC Dashboard</td><td>Yes</td></tr><tr><td><strong>Delay breakdown by reason, subcontractor &#x26; owner</strong></td><td>Delay Breakdown</td><td>Partial</td></tr><tr><td><strong>Milestone status &#x26; movement over time</strong></td><td>Milestone Analysis</td><td>Yes (Variance template)</td></tr><tr><td><strong>Planned Labour / Plant / Material demand</strong></td><td>Resources</td><td>Yes</td></tr></tbody></table>

<details>

<summary>How the PPC calculation differs from Power BI</summary>

Where PPC and Task Progress appear in both tools, the Project Insight figures are more accurate, and will usually read higher than the Power BI template. The difference comes down to working days vs calendar days.

**Project Insight** is computed server-side off the full published plan, so it knows each task's working calendar and counts working days only. The result reflects what the team actually committed to.

**Power BI** runs on the Published Plan API, which (to stay under the data limit on large projects) sends only each task's start and end date. With no working-calendar detail, it spreads progress across calendar days, including weekends and non-working days. This stretches the denominator, so PPC and Task Progress read lower than the plan actually asked for.

Because the calculation runs server-side, Project Insight also scales to large projects that can strain or break the Power BI feed.

</details>

## What Project Insight doesn't cover yet

***

For the following, continue to use the Power BI integration:

* **Plan Comparison** - compare the full plan between any two Published Versions at the task level. Useful for schedule audits and board reporting.
* **Publication Summary** - readying completion, clashes, and blocker counts per user per publication. Useful for publication quality monitoring.
* **Resource actuals** - Project Insight currently shows planned Labour, Plant, and Material only. Actuals (fed from the Site Diary) are coming next.

If you already have Power BI connected, these templates continue to work as before.

See also <a href="/docs/integrations-and-api/power-bi/getting-started-with-power-bi-reporting.md" class="button secondary">Connect Aphex to Power BI</a>


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://help.aphex.co/docs/insight/insight-and-power-bi.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.