Power BI with Pronto Xi: What to Check Before Building Dashboards
A practical framework for deciding whether to use Power BI with Pronto Xi, covering access routes, reconciliation, freshness, security, licensing and what a pilot must prove before rollout.
Power BI can analyse Pronto Xi data where a suitable, authorised access route is available. Before investing, establish that the reporting need justifies the cost, the proposed solution can deliver accurate and secure information, and a pilot can prove the required performance and business value.
Do not assume your installation includes a native Power BI connector or unrestricted database access. Identify the exact connection method, prerequisites, licensing and support responsibilities.
For CFOs, CIOs and IT leaders, the project comes down to three decisions:
- Is Power BI justified?
- Can we deliver trustworthy reporting?
- What must the pilot prove before rollout?
This article provides a recommended assessment framework. Product-specific statements are sourced, and worked examples are hypothetical. Validate the design against your actual Pronto Xi environment.
Decision 1: Is Power BI justified?
Start with the decision the business needs to make. A dashboard has value when people use its information to take useful action.
For each proposed report, identify the user, decision, required data, frequency and expected benefit. Establish what is difficult today and how improvement will be measured.
Pronto Software documents built-in business intelligence powered by IBM Cognos Analytics. Assess whether existing reporting can meet the requirement before adding another platform. Confirm the capabilities and entitlements in your installation.
Power BI may merit investigation where the organisation needs to combine systems, use an established reporting platform or meet a specific analytical need. Compare those benefits with additional modelling, security, training and support costs.
Should you proceed, investigate or pause?
| Finding | Recommended decision |
|---|---|
| The need is clear, access is authorised and required data is available | Proceed to a bounded pilot |
| Data definitions, historical coverage or performance remain uncertain | Fund a defined investigation first |
| Required access cannot be authorised, security cannot be enforced or critical figures cannot be reconciled | Pause implementation until the gap is resolved |
| Existing reporting meets the requirement at lower total cost | Improve the existing solution |
An investigation should have a specific question, an effort or spending limit, an owner and a decision date.
Connect ROI to an observable action
The following is an illustrative measurement framework, not a claim of achieved results.
| Element | Example: overdue receivables |
|---|---|
| Decision | Which overdue accounts require action? |
| Business owner | Credit-control lead |
| Action | Prioritise accounts and assign follow-up |
| Adoption measure | Report use in the agreed review, with follow-up recorded |
| Outcome measures | Preparation effort, follow-up timeliness and overdue balances |
| Attribution checks | Changes in sales volume, customer mix, payment terms and staffing |
Measure reporting effort before and after implementation. Report time released as capacity unless spending actually changes. Assess collection outcomes over a defined period and consider other influences before attributing improvement to the reporting project.
Price the production service
Ask for an estimate covering data access, extraction, modelling, reconciliation, reports, security, training and ongoing operation. Include upgrades and changes to data structures.
For licensing, resolve four questions:
- Who creates and publishes content?
- Who consumes it?
- Is it shared internally, externally or through an embedded application?
- Which licence or capacity arrangement hosts the content?
Licensing note, checked 4 October 2026: Microsoft's documentation distinguishes paid authoring/sharing, PPU access and qualifying capacity for free-user consumption. For the documented Fabric Power BI consumption scenario, free viewers require F64 or above; smaller Fabric capacities do not provide that entitlement. Confirm current terms for the intended deployment rather than assuming all viewers are covered.
Decision 2: Can we deliver trustworthy reporting?
A successful connection proves that data can be retrieved. Production reporting also needs supported access, correct definitions, reconciliation, freshness, security and accountable operation.
Confirm the access route and support boundaries
Ask the proposing supplier to identify whether the design uses approved extracts, database views, a reporting store, APIs or a partner connector.
Pronto Software describes Pronto Connect as a platform for integrating external applications with Pronto Xi. This does not establish an included native Power BI connector or analytical coverage of every required dataset.
Confirm required fields, history, authentication, update handling and any access restrictions. For a partner connector, identify its supplier, supported versions, licensing and upgrade responsibilities.
“Supported” should be explicit at each layer:
| Support area | Confirm in writing |
|---|---|
| Pronto application | Permitted access methods, relevant data definitions and upgrade implications |
| Hosting and infrastructure | Connectivity, credentials, extraction windows and workload limits |
| Connector or extraction process | Compatibility, monitoring, retry behaviour and failure resolution |
| Data model and Power BI | Transformations, measures, refresh, security and report maintenance |
| Complete reporting service | Incident coordinator, escalation route and recovery acceptance |
Appoint one service owner to coordinate incidents across suppliers. Each provider supporting its component does not automatically establish ownership of the end-to-end result.
Match architecture to the requirement
Use these as assessment starting points, subject to authorised access and technical validation.
| Requirement | Option worth evaluating | Main trade-off |
|---|---|---|
| Small periodic report with modest volumes | Controlled extracts and Import | Simple scope, but file completeness and delivery need controls |
| Several reports needing consistent calculations | Governed reporting source and shared model | Reusable definitions, with additional stewardship |
| High-frequency operational decisions | Supported low-latency extraction or query route | Greater demands on performance, availability and monitoring |
| Multiple systems and historical analysis | Reporting store with defined integration and history rules | Broader capability, with more implementation and operating cost |
A read-only account restricts writes; it does not remove query load. Test the effect on ERP processing and agree extraction windows and workload limits.
Microsoft distinguishes Import, which stores selected data in the model, from DirectQuery, which queries a supported source during report interaction. DirectQuery availability depends on the source and connector. A DirectQuery report against a delayed replica still sees delayed data.
Validate the published Power BI service connection as well as the desktop connection. A gateway may be required, depending on the source and network. Microsoft documents gateways for relevant connections between Power BI and data sources. Assign ownership of gateway administration, credentials and recovery.
Agree the meaning of each measure
Define calculations and relationships with finance and process owners before designing visuals.
| Measure | Definitions to settle |
|---|---|
| Revenue | Order, invoice or ledger basis; credits; tax; currency; reporting date |
| Margin | Cost basis, adjustments, rebates and timing |
| Receivables ageing | Due dates, credits, partial payments and historical cut-off |
| Inventory | On-hand versus available; allocation; units; warehouse and valuation basis |
| Backlog | Included statuses, cancellations, partial fulfilment and date basis |
Specify the level of detail in each dataset. Invoice headers, invoice lines and payment allocations are different levels; an incorrect join can duplicate amounts.
For master data, define stable identifiers and whether analysis uses today's classifications or classifications applicable at the time. Preserve the history needed to answer that question.
Reconcile totals, detail and changes
Agree a reference report or control dataset and validate its parameters and calculation basis. An existing Pronto report is a reference to understand, not automatic proof that every number is correct.
Match entity, period, currency, filters, status and extraction cut-off. Then verify completeness, totals and representative transactions.
Worked example: a correct total that later goes wrong
This hypothetical dataset uses AUD amounts excluding GST.
| Document | Detail | Header amount |
|---|---|---|
| Invoice A | Two lines: $600 and $400 | $1,000 |
| Invoice B | One line: $500 | $500 |
The initial invoiced total is $1,500.
If a model joins headers to lines and sums the repeated header amount, Invoice A may be counted twice. The incorrect total becomes $2,500.
The correct model must produce $1,500 at the overall level and the expected amounts when drilling into lines.
After the initial extraction, a $200 credit against Invoice A is posted within the same agreed reporting period. The next completed load should produce $1,300 net invoiced value.
| Test | Pass condition |
|---|---|
| Initial total | $1,500 |
| Drill into Invoice A | Two lines totalling $1,000 |
| Load the later credit | Net total becomes $1,300 |
| Rerun the same load | Total remains $1,300, with no duplicate documents |
| Filter to Invoice A and its credit | Net value is $800 |
Also test corrections to previously loaded records, deletions or reversals where relevant, and changes outside the usual refresh window. A process that loads only newly dated rows may miss updates to older records.
Document tolerances and investigate unexplained differences. Obtain business-owner approval of the reconciled result.
Separate freshness from reproducibility
These requirements are different:
| Business question | Data requirement |
|---|---|
| What is the latest available position? | Timely updates, including relevant corrections |
| What did management see last Tuesday? | A retained snapshot or another reproducible historical record |
| What was reported for the closed financial period? | An approved reporting basis and controlled treatment of subsequent adjustments |
A current refresh timestamp cannot prove that a report reproduces a previous result. Agree whether historical figures may restate and how users will recognise revised numbers.
Define freshness across extraction, transfer, transformation, model refresh and display. A successful refresh may still import yesterday's source file.
Record the maximum acceptable data age, cut-off and time zone, late-load detection, user-facing stale-data status and recovery owner. Show a meaningful data-as-at time separately from refresh completion where needed.
Microsoft documents scheduled-refresh limits and circumstances in which refresh schedules are disabled after failures. Check the applicable limits, but assess actual end-to-end performance rather than relying on the schedule alone.
Test security with real user roles
Do not assume that Pronto permissions transfer to extracted data. Define access in the reporting environment, including sharing, export, download and model-building permissions.
The following is an illustrative test matrix. Replace roles and entitlements with approved requirements.
| Test user | Permitted information | Prohibited information | Export requirement |
|---|---|---|---|
| Finance viewer | Approved entities and finance measures | Excluded sensitive fields | Only approved export options |
| Regional manager | Assigned region | Other regions | Restricted to permitted data |
| External guest, if in scope | Explicitly approved subset | All other business data | Disabled unless authorised |
| Report developer | Approved development data and editing scope | Unauthorised production data | Controlled under development policy |
For each test, record the expected result and actual result in the published service, including attempts to obtain prohibited data.
Microsoft states that row-level security applies to workspace Viewers, while Admin, Member and Contributor roles are not restricted by those RLS rules. Treat editing privileges as a separate access decision.
Hidden columns and page filters are not substitutes for security. Review extraction credentials, development copies and offboarding as well.
Use authenticated sharing for confidential ERP information. Microsoft's Publish to web makes content publicly accessible and can expose underlying model data.
Decision 3: What must the pilot prove before rollout?
Choose one valuable use case, a limited audience and representative data. Agree measurable pass conditions before development.
Copyable pilot assessment checklist
| Area | Evidence required | Sign-off owner |
|---|---|---|
| Value | Defined decision, action, baseline and benefit measure | Business sponsor |
| Access | Authorised route, prerequisites and support boundaries | ERP/IT owner |
| Accuracy | Reconciled totals, relationships and exception tests | Finance/process owner |
| Security | Approved access succeeds; prohibited access fails | Security and business owners |
| Freshness and history | Data-age target met; historical reporting rules demonstrated | Business and data owners |
| Performance | Agreed workload meets response targets without unacceptable ERP impact | Technical lead |
| Recovery | Failures detected, assigned and recovered without duplication | Service owner |
| Cost and licensing | Production audience, entitlements and operating estimate confirmed | Sponsor/procurement |
| Handover | Documentation, monitoring and maintenance responsibilities accepted | ERP/BI service owner |
Replace phrases such as “acceptable response time” with a defined workload, threshold and measurement method. Record outstanding gaps rather than marking an area complete because it was discussed.
Test failure as well as success:
- A source file is stale although model refresh succeeds.
- Extraction fails or credentials expire.
- A correction arrives after the initial load.
- A refresh or load is retried.
- An unauthorised user attempts access.
Specify when a report should display a warning or be withdrawn from operational use. Confirm who decides it is safe to rely on again.
Proceed to rollout when the pilot demonstrates accurate, secure and usable reporting at a manageable cost. If it exposes unresolved access, definition or security gaps, return to investigation before expanding.
Match the expertise to the reporting problem
Pronto process knowledge, data engineering, Power BI modelling and security are distinct capabilities. Business owners must also approve definitions and act on the results.
Read SAAPRO's guide to Pronto Xi roles or Contact SAAPRO to discuss the reporting outcome, existing systems and expertise needed to deliver it.
Frequently Asked Questions
Power BI can analyse Pronto Xi data where an authorised, compatible access route is available. This may involve extracts, a reporting source, APIs or a partner solution. Confirm data coverage, support responsibilities, licensing and production-service connectivity before selecting the design.
Do not assume one is included. The cited Pronto documentation describes Cognos-based business intelligence and Pronto Connect integration capabilities; it does not establish an included native Power BI connector. Ask the supplier to identify the proposed connector, prerequisites, support and costs.
Compare the specific business requirement with your existing reporting capabilities and entitlements. Power BI may suit a wider reporting strategy or a defined analytical need. Include duplicated modelling, reconciliation, security, training and support in the comparison before maintaining both platforms.
No. DirectQuery queries a supported underlying source, which may be a delayed replica or reporting store. Display behaviour and network performance also matter. Agree and measure the maximum data age across the whole architecture rather than equating the connection mode with live data.
Differences can arise from reporting dates, filters, statuses, credits, currency, calculation definitions, missing updates or duplicated amounts from joins. Validate both the reference report and the Power BI model on the same basis, then investigate differences at transaction level.
Require a clear business use, reconciled figures, approved access controls, demonstrated freshness and recovery, and a complete operating-cost estimate. Assign owners for adoption and benefit measurement. A working demonstration should progress to rollout only after the agreed pilot criteria are met.
Key Takeaways
- ✓Power BI can analyse Pronto Xi data only where a suitable, authorised access route exists. Do not assume a native connector or unrestricted database access.
- ✓Start with the business decision the dashboard supports, and check whether existing Cognos-based reporting can meet the need before adding another platform.
- ✓Make "supported" explicit at every layer, and appoint one service owner for the end-to-end reporting service.
- ✓Agree measure definitions and data grain with finance and process owners before building visuals, then reconcile totals, detail and later corrections.
- ✓Freshness and reproducibility are different requirements. A successful refresh does not prove the data is current or that past results can be reproduced.
- ✓Test security with real user roles in the published service. Hidden columns and page filters are not security controls.
- ✓Approve rollout only when a bounded pilot meets agreed pass conditions for value, access, accuracy, security, freshness, performance, recovery and cost.
