A practical guide to supporting Power BI
Power BI Support Services: What Should Your Support Plan Include?
Define how your reporting will be kept reliable, who owns each issue and how maintenance differs from new development.
At a glance
Make support specific
- Define the scopeReports, data, access and the systems they depend on.
- Separate fixes from changeMaintenance, enhancements and new development.
- Agree the operating planOwnership, response definitions and escalation.
On this page
Power BI support services should make it clear how existing reporting will be monitored, maintained and corrected, and how requests for change will be handled. A useful plan covers the technical work, the business responsibilities and the route to help when something goes wrong.
Refresh failures, changing source systems and access problems can all interrupt reporting. A plan that simply offers “dashboard support” leaves too much open to interpretation.
Microsoft’s support and monitoring guidance treats ongoing support as part of the content lifecycle. For the earlier delivery stages, see our Power BI implementation guide. Here, the focus is what happens once people rely on the solution.
01 · Define what is covered
Start with an inventory and clear ownership
A support plan should identify the reports, semantic models, workspaces, dataflows and connections it covers. Record their business owners, technical owners, audiences, refresh expectations and important reporting deadlines. Clarify whether the supplier supports content built by another developer and whether an initial assessment is needed.
Separate Power BI responsibilities from the systems it depends on. A reporting specialist may diagnose a failed connection while your IT team owns the gateway server and the source-system team owns the database. Name those dependencies and the people who can act on them.
Agree how existing defects and undocumented components will be treated at the start. A support agreement should make its starting position visible, including any stabilisation work needed before routine support begins.
02 · Keep data trustworthy
Refresh failures: cover detection, diagnosis and recovery
Ask whether refresh failures are monitored proactively or investigated only after a user raises a ticket. Agree who receives alerts, when they are reviewed and how an absent owner is covered. An automated notification is not the same as someone taking responsibility for it.
For imported data, the investigation may involve refresh history, credentials, gateway availability, query errors or capacity constraints. Microsoft’s refresh troubleshooting guidance describes several possible causes. DirectQuery connectivity issues need their own treatment rather than being assumed to follow the same refresh process.
The recovery check should confirm both that the process runs and that the expected data has arrived. Agree how users will be told when figures are stale, what workarounds are acceptable and how recurring failures lead to a permanent fix.
03 · Manage dependencies
Source-system changes need an early warning route
An ERP upgrade, renamed column, changed API or revised file format can affect a report even when nobody has changed Power BI. The plan should identify who tells the support team about upstream releases and how much notice is needed for impact assessment and testing.
Ask whether the supplier will assess affected queries, transformations, measures and reports, and who provides test data or access to a test environment. Check business meaning as well as technical compatibility: a field can retain its name while its definition changes.
Do not assume every source-system change falls within maintenance. A small compatibility fix and a migration to a replacement platform involve different work. Agree how the supplier classifies, estimates and obtains approval for changes before starting them.
04 · Support the right users
Access issues: diagnose the cause and respect approvals
“I cannot see the report” can mean several things: the wrong distribution link, missing group membership, licensing, workspace or app permissions, or a data-access rule. Record the affected user, report, error and intended level of access so the support team can investigate the actual problem.
Name who approves new access and who implements it. Include joiners, movers and leavers, group ownership and the process for checking row-level security where it applies. Restoring an authorised user’s view and granting additional access are different requests.
If users can see information they should not, define an urgent route to the client’s security owner. Any investigation or change should follow the organisation’s approved access process.
05 · Diagnose before changing
Report defects: agree what correct behaviour looks like
A report defect might be an incorrect calculation, a broken filter, an unusable page or a navigation link that no longer works. Ask the supplier to capture the steps to reproduce it, the affected version and the expected result. Differences can also originate in source data or a misunderstood business definition.
Agree who validates corrected figures and which related reports must be checked before a fix is released. The plan should cover proportionate testing, release approval, retained versions and a rollback route where needed.
Close the ticket with the fix, validation evidence and any remaining limitations recorded. For repeat incidents, ask how underlying causes and preventive actions will be reviewed instead of treating every recurrence as an unrelated ticket.
06 · Separate the work clearly
Maintenance, enhancements and new development
Maintenance keeps the agreed solution operating; development changes what it does. Use concrete examples in the scope document so both sides can classify requests consistently.
| Type of work | Purpose | Illustrative examples |
|---|---|---|
| Maintenance | PurposeKeep an agreed solution working as intended. | Illustrative examplesInvestigate a failed refresh; correct a measure that no longer matches its agreed definition. |
| Enhancement | PurposeChange or extend the existing behaviour. | Illustrative examplesAdd a new drill-through page or change the business definition of a KPI. |
| New development | PurposeIntroduce a new capability or substantial redesign. | Illustrative examplesConnect a new source system, build a new reporting area or replace the semantic model. |
These examples are a starting point, not automatic charging rules. An agreement may include a defined allowance for small enhancements, or price changes separately. Ask how effort limits, unused capacity and work beyond the allowance are handled, and whether investigation time counts towards it.
Record the accepted reporting requirements so a defect can be distinguished from a new request. Our Power BI reporting brief guide helps establish that baseline. New requirements should enter a prioritised change backlog with an estimate and approval route.
07 · Make knowledge accessible
Documentation should be part of ongoing support
Ask for a maintained inventory, data and measure definitions, dependency map, access model, refresh instructions and a record of changes. An operational runbook should explain common failures, diagnostic steps, escalation contacts and how to recover the service.
Keep editable project files and agreed source artefacts in an accessible, controlled location. Record who owns credentials and how authorised staff manage them through approved systems; passwords should not be copied into support tickets or general documentation.
Agree who updates the documentation after each change, how cover works when the usual specialist is unavailable and what is handed over if the support arrangement ends. These are practical tests of whether knowledge belongs to the service or stays with one person.
08 · Define what the clock measures
Response times and escalation need precise definitions
A promise of a “quick response” is difficult to evaluate. Distinguish the stages of handling an issue:
- Initial response: a person acknowledges and assesses the request, as defined in the agreement.
- Restoration or workaround: users can resume an agreed activity, even if a permanent correction is still pending.
- Resolution: the underlying issue is corrected and validated.
- Progress updates: users know the current position, next action and owner.
Set priorities using business impact, affected users, deadlines and available workarounds. A failure affecting a critical reporting cycle may need different handling from a cosmetic issue on an infrequently used page.
Specify coverage hours, time zone, holidays, when the clock starts and any agreed pauses while waiting for information or third parties. Define the escalation contact, deputy and triggers for involving client IT, a source-system supplier or Microsoft. Keep one person responsible for coordinating updates even when another team owns the fix.
Agree service levels explicitly. Response and resolution targets, out-of-hours cover and any service commitments must be confirmed in the individual support agreement. This guide does not set or promise Denova service levels.
A related Data & BI client story
Continuity matters alongside improvement
Denova’s global finance-team case study describes an engagement spanning recurring finance and commercial reporting, dashboard development, automation and data quality work.
Colleagues built knowledge of the organisation’s reporting cycles and processes while supporting further initiatives. The client provided business direction and context, while Denova supported its colleagues through management, training and mentoring.
The useful lesson for a support plan is to make ongoing responsibilities and improvement work explicit, while retaining the knowledge needed to deliver both.
Read how a global finance team developed capability and retained knowledge through an ongoing engagement.
Take these into the supplier conversation
Questions to ask about Power BI support services
Use these questions to compare proposals and resolve assumptions before an issue becomes urgent.
- Exactly what is covered? Which assets, environments, users and dependencies are included, and what is excluded?
- Who notices problems? Is monitoring included, who reviews alerts and how are stale data or connectivity issues communicated?
- What does each response target mean? Is it a human assessment, a workaround or a completed fix, and how is performance measured?
- When is support available? Which hours, time zone and holidays apply, and what happens outside that window?
- How are priorities agreed? Who can raise or change severity when a business deadline or impact changes?
- How is work charged and limited? What counts towards an allowance, and how are investigations, enhancements and excess demand approved?
- Who handles external dependencies? Who contacts IT, source-system vendors or Microsoft, and who keeps us informed?
- How are changes tested and released? Who approves them, validates the outcome and decides whether to roll back?
- How is knowledge maintained? What documentation, cover and exit handover are included?
- How will we review the service? Will reviews cover recurring incidents, time against agreed targets, capacity used and improvement priorities?
Copy into your support process
Give the support team a useful starting point
A consistent request format reduces avoidable back-and-forth. Copy these fields into your ticket form or support procedure, and send evidence through the agreed channel.
Use only the information needed to diagnose the issue. Share sensitive examples through approved channels and exclude passwords or tokens.
Plan the next step