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.

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.

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.

1. Exactly what is covered? Which assets, environments, users and dependencies are included, and what is excluded?
2. Who notices problems? Is monitoring included, who reviews alerts and how are stale data or connectivity issues communicated?
3. What does each response target mean? Is it a human assessment, a workaround or a completed fix, and how is performance measured?
4. When is support available? Which hours, time zone and holidays apply, and what happens outside that window?
5. How are priorities agreed? Who can raise or change severity when a business deadline or impact changes?
6. How is work charged and limited? What counts towards an allowance, and how are investigations, enhancements and excess demand approved?
7. Who handles external dependencies? Who contacts IT, source-system vendors or Microsoft, and who keeps us informed?
8. How are changes tested and released? Who approves them, validates the outcome and decides whether to roll back?
9. How is knowledge maintained? What documentation, cover and exit handover are included?
10. 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.

01 · Identify the symptom

Slow interactions and slow refreshes need different checks

Slow report interactions are the delays users experience when opening a page, changing a slicer, drilling into detail or selecting a chart. Investigate the query behind the visual, the work needed to draw it and the environment serving it.

Slow data refreshes are delays in bringing updated data into an Import semantic model. The work can include reading sources, transforming data, loading tables and processing the model. Start with refresh history and compare duration, failures and data volumes across recent runs.

A visual refreshing on screen is not the same as a semantic model loading new data. With DirectQuery, report interactions can send queries to the underlying source, so source performance can directly affect the user’s wait. Record the actual storage mode before choosing a remedy.

02 · Establish a baseline

Measure a repeatable user journey

Choose an important task, such as opening the monthly finance page and filtering to one entity. Record the report version, page, filters, user or security role, data volume, time and environment. Include whether the delay happens in Desktop, the Power BI service or both.

Use Performance Analyzer to record the interaction and inspect timings by visual. It separates categories including DAX query, visual display and other activity. “Other” can include waiting for other visuals; it is not a diagnosis of slow DAX. Export the results for comparison.

Repeat the same sequence. Keep first-load and repeated-load observations separate because caching can change the result. A single fast run on a developer’s laptop does not establish the experience of users during a busy reporting period.

03 · Review the foundation

Check the semantic model before rewriting every measure

The semantic model is the layer of tables, relationships and calculations behind the report. Microsoft’s star-schema guidance explains how fact tables for business events and dimension tables for filtering and grouping support usable, efficient models.

Check that tables have a consistent level of detail and that relationships match the business logic. Review unnecessary relationship complexity and filter paths with the developer. A model change must preserve intended filtering and row-level security.

For Import models, inspect unused columns, unnecessary history and columns containing many distinct values. Reducing unnecessary imported data can reduce model size and refresh work. Hiding a column does not remove its stored data.

Agree the detail users need before removing anything. Summarising invoice lines may help some reporting workloads, but it can remove the ability to investigate individual transactions. Document that trade-off and check dependent reports.

04 · Investigate expensive calculations

Use timings to focus DAX work

Start with the measures used by the slow visuals. Copy the visual’s query from Performance Analyzer and investigate it under the same filters that reproduce the problem. A long formula is not automatically the slowest formula, and query time can reflect the model and source as well as the measure.

Look for repeated calculations and logic that asks for more work than the result requires. Microsoft’s guidance on DAX variables shows how storing a repeated expression can avoid recalculating it and make a measure easier to inspect. Treat this as a technique to test, not a universal speed guarantee.

Compare totals, subtotals, blank values and different filter selections after each rewrite. A faster measure that changes the agreed KPI definition is a defect, not an improvement.

05 · Reduce unnecessary work on screen

Review visuals, interactions and detail

Inspect pages with many visuals, large tables or matrices and broad default selections. Ask which information users need immediately and which belongs on a drill-through page. Check whether every visual needs to respond to every selection.

Microsoft’s Power BI optimisation guide recommends limiting unnecessary visuals, reducing the data displayed and testing custom visuals. Use the timing evidence to distinguish a slow query from a visual that takes a long time to draw.

Test a simpler presentation or narrower default view in a copy of the report. Preserve the route to necessary detail and explain any changed navigation. A cleaner page should still help people make the decision it was designed for.

06 · Follow the data path

Check sources, transformations and refresh design

When data retrieval is slow, involve the source owner. Compare the relevant query or extract at the source with the Power BI run. Check recent changes in volume, database workload, API behaviour, file organisation and gateway health where a gateway is used.

In Power Query, query folding pushes supported transformations to the source. Check whether filtering and other costly steps are handled there or in the Power Query engine. Folding depends on the connector and transformations; Excel and CSV files do not offer a database query engine to fold into.

For growing Import tables, assess incremental refresh. Refreshing an appropriate recent window can avoid repeatedly reloading all history. Verify that date filtering actually limits the data retrieved and that the policy accounts for late-arriving records and corrections to older transactions. Plan and test the initial historical load separately.

Agree an acceptable freshness window with the business. Changing the schedule can ease contention, but it must still make the required data available before users need it.

07 · Check shared resources

Investigate capacity when the pattern points to it

If several reports slow down together, especially at busy times, investigate shared resources as well as individual reports. Compare incident timestamps with refresh activity, user demand and other workloads.

Where the workspace uses a supported dedicated capacity, ask the administrator to review the Microsoft Fabric Capacity Metrics app for utilisation, expensive operations and throttling. The available evidence depends on the environment and the administrator’s access.

Also compare gateway and network conditions, particularly when the service behaves differently from Desktop. Changing capacity may be justified by measured demand, but first establish what resource is constrained and whether reducing avoidable work would address it. Record the cost and expected benefit of any proposed capacity change.

Use this in your review

Power BI performance optimisation checklist

Work through the symptoms that apply. Each row is a starting point for investigation, not proof of a particular cause.

Keep report responsiveness and data freshness as separate acceptance measures. Improvements in one do not automatically establish improvements in the other.

08 · Prove the improvement

Compare like for like and protect correctness

Ask for a short record of the baseline, identified bottleneck, proposed change and result. Repeat representative journeys using comparable data volumes, filters, roles and load conditions. Keep first-load and repeated-load results separate, and include refresh completion and data freshness where relevant.

Make controlled changes with retained versions and a rollback route. Reconcile key figures, test security roles and check other reports sharing the model. Agree realistic acceptance criteria with users; there is no single response-time target that suits every report.

Our Power BI reporting brief guide helps define the required behaviour. Once changes are accepted, the Power BI support services guide explains how to maintain ownership, documentation and escalation.

Copy into your investigation

Give the investigation a useful starting point

Copy these fields into a support ticket or optimisation brief. Include enough evidence to reproduce the issue, and share sensitive examples through your approved channels.

01 · Establish the scope

Discovery: agree the outcome and the boundaries

Discovery should produce a shared delivery plan, not simply a list of reports. Identify the business problem, the first user group, the decisions the solution will support and what a successful first release looks like. Include business sponsors, operational users, data owners and IT early.

Ask for a prioritised scope, an outline architecture, dependencies, risks and named decision-makers. Agree what is excluded: source-system changes, historical data cleansing, new integrations and ongoing support can each materially affect cost and timing.

Before moving on: both sides should understand the proposed first release, who can approve it and which assumptions still need testing. If data access is uncertain, use a bounded discovery phase before committing to a fixed build estimate.

02 · Establish the foundations

Data readiness: prove the sources can support the solution

A working connection does not establish that data is ready. The supplier should inspect representative records, history, volumes, identifiers and update patterns. Missing supplier codes, duplicate transactions or inconsistent entity names should appear in a documented issue log, with an owner and a treatment for each issue.

Confirm the route from source to Power BI, including any preparation layer, gateway requirement, credentials and refresh dependencies. Agree how source changes, failed loads and late data will be detected and handled. Make recurring infrastructure and licensing costs visible.

The client’s role: provide approved access, source-system expertise, representative samples and a person authorised to resolve data questions. Decide whether each quality issue will be corrected at source, handled in transformation or accepted as a documented limitation.

03 · Build a reusable foundation

Modelling: make the numbers consistent and maintainable

The semantic model is the layer that organises data and business calculations for reporting. The implementation scope should include its design, transformations, relationships, shared measures and documentation, rather than leave these hidden inside a finished report.

Ask how the model will handle the level of detail in each source, financial periods, organisational hierarchies and changes over time. For example, purchase-order lines and invoice lines cannot safely be treated as though they are the same record.

Microsoft’s star schema guidance explains why fact and dimension tables, consistent grain and well-designed relationships matter for model usability and performance. The supplier should explain the choices in business terms and reconcile key totals to agreed source records.

04 · Make control explicit

Governance: decide who can access, change and share content

Agree ownership and access before rollout. The design should cover workspaces, user groups, distribution, authoring permissions and any restrictions on the records different audiences can see. Ask the supplier to demonstrate access using representative user accounts, including a user who should be denied access.

Confirm the appropriate licensing and capacity for the intended audience, security requirements and release approach. Identify who approves sharing, manages membership and reviews access when people change roles. Where row-level security is required, include its configuration and validation in the scope.

Governance should fit the organisation’s existing policies and the scale of the solution. Microsoft’s implementation planning guidance covers these wider decisions, including workspaces, security, gateways and administration.

05 · Agree the evidence

Testing: validate the whole service before sign-off

User acceptance testing needs more than a demonstration of attractive pages. Agree test scenarios and expected results during discovery, then test the data, calculations, access, refresh process and main user journeys together.

• Accuracy: reconcile agreed totals and investigate differences, including exclusions and rounding.
• Security: check permitted and restricted views for representative roles.
• Reliability: test refresh, failure handling and recovery with realistic dependencies.
• Usability and performance: check everyday tasks using representative data volumes and agreed response expectations.

Keep evidence, a defect log and retest results. Name the business approver and agree which issues block release, which can be accepted and who owns any remaining work. Do not leave acceptance as “the dashboard looks right”.

06 · Release with a plan

Rollout: move into production in a controlled way

The supplier should document how development, testing and production will be separated, how versions are retained and how changes reach users. Choose an approach proportionate to the solution and available licensing; a complex release pipeline is not automatically necessary for a small deployment.

Start with a representative pilot group where practical. Agree the release window, user communications, access checks, support contacts and a fallback plan. Decide when existing reports can be retired, and whether a parallel run is needed to build confidence in the new numbers.

Microsoft’s content lifecycle guidance extends beyond deployment to support, monitoring and retirement. A supplier’s proposal should make that transition explicit.

07 · Prepare people to use it

Training: distinguish users, report owners and administrators

Training should reflect what each group will actually do. Users need to find the right content, interpret it, apply filters and raise questions. Internal report owners need to understand definitions and make agreed changes. Administrators and support teams need the operational steps for access, refresh and incident handling.

Ask for practical sessions using the delivered solution, supporting notes or recordings, and time for questions. Include process owners where users may be unclear about the underlying business process as well as the technology.

Agree how adoption will be reviewed after launch: for example, whether intended users can complete their main tasks and whether old spreadsheet workarounds are still needed. Attendance alone does not demonstrate readiness.

08 · Make ownership sustainable

Handover: leave a service the client can own

Handover should start during delivery. Name a business owner for priorities and definitions, a technical owner for the model and reports, and an operational owner for access, refresh and support. One person may hold several roles, but none should be assumed.

Request editable project files and agreed source artefacts, model and transformation documentation, a data dictionary, release instructions, test evidence and an operational runbook. Confirm where these are stored, the client’s rights to use and change them, and how authorised staff will manage credentials without relying on a departing individual.

Define any initial support period: its duration, coverage, response expectations and exit criteria. Separate defect correction from new features. The final check is practical: can the receiving team manage access, investigate a failed refresh and make a controlled change?

Copy into your scope document

Power BI implementation services checklist

Use this checklist when reviewing a proposal or planning delivery. Copy it into your working document and add a named owner, target date and approval evidence for each stage. Tick a stage when the agreed deliverables have been accepted.

Before appointing a supplier

Compare the scope behind the price

Ask each supplier to separate discovery, build, rollout and ongoing support, and state the assumptions behind the estimate. Check what happens when testing reveals an additional requirement: who assesses the impact, approves the change and updates the plan?

Confirm third-party costs, documentation, editable artefacts, internal training and post-launch support explicitly. The right scope depends on your starting point; an established Power BI environment may need targeted work, while a first implementation needs more foundations.

A strong proposal makes the client’s commitments as clear as the supplier’s deliverables. Both are necessary for a solution that can be used and maintained.

01 / Users and decisions

Start with the people and the actions

List the audiences separately. A finance director reviewing month-end performance needs a different view from an analyst investigating transactions or a procurement manager chasing overdue approvals.

For each audience, write down the question they need answered, when they will use the information and what they will do next. Include the number of users, their familiarity with Power BI and whether they work on a laptop, phone or shared meeting screen.

Choose the essential decisions for the first release. Put additional countries, historical analysis and future integrations into a separate backlog, with a named person responsible for approving scope changes.

02 / Measures and accountability

Define each KPI before agreeing the visuals

A label such as “spend”, “savings” or “on-time approval” is not a complete definition. Record the calculation, business meaning and owner of each measure.

• Calculation and scope: numerator, denominator, unit, currency and exclusions.
• Time rules: reporting period, relevant date, calendar and treatment of late changes.
• Interpretation: target, threshold and the action a change should trigger.
• Approval: the business owner who will resolve disputes and sign off the result.

For on-time approvals, agree whether the denominator includes all items due in the period or only completed items, how reopened items count and whether weekends affect the deadline. Bring worked examples and a trusted comparison report so those choices can be checked.

03 / Source data and readiness

Explain where the data comes from

List the systems, files, tables or approved interfaces needed, together with their owners and access arrangements. Provide representative samples, field definitions, expected volumes and the history required.

Specify what one row represents: an invoice, an invoice line or an approval event. Identify the keys that connect sources, such as supplier and entity identifiers. Mixing different levels of detail can produce misleading totals.

Be explicit about duplicate records, missing dates, inconsistent supplier names and spreadsheet adjustments. Agree which issues must be fixed at source, which transformations belong in the reporting solution and who owns each task. If access or quality is uncertain, ask for a discovery stage before committing to the full build.

04 / Deliverables and layout

Specify the report experience, not just the charts

In everyday conversation, “dashboard” often means any reporting screen. In Power BI, a dashboard is a single-page canvas in the Power BI service, often using tiles from reports. A report has one or more pages and supports filtering and deeper exploration. Microsoft explains the difference between dashboards and reports.

State whether you need an interactive report, a service dashboard or both. An overview page within a report may meet the need without a separate dashboard.

Sketch the journey from summary to detail. Define page purpose, default filters, comparisons, drill-through and navigation. Include any mobile layout, export or meeting-pack requirements, plus accessibility needs such as readable labels and meaning that does not depend on colour alone. Review a simple wireframe with representative users before polishing the visuals.

05 / Access and distribution

Agree who can see and change what

Create an access matrix covering viewers, editors, administrators and external users. For each group, specify which entities, regions or teams they may see, how they receive the report and whether they may export or reuse the underlying data.

If users must see different rows, describe the required row-level security (RLS) rules and test identities. A country manager might see one country while a group finance user sees all entities. Include users who should see no data.

Confirm workspace roles carefully: Microsoft’s RLS guidance explains that workspace Admin, Member and Contributor roles are not restricted by RLS. Ask IT and the delivery team to confirm the sharing method, licensing and access-removal process before sign-off.

06 / Refresh and freshness

Say when the figures must be ready

“Daily refresh” does not say how current the information needs to be. Specify the source cut-off, reporting deadline, time zone and acceptable delay. For example, figures through the previous working day may need to be ready for a 09:00 UK review.

Separate source availability from the time Power BI finishes updating. Agree how users will see the last successful refresh and the period covered, what happens after a failure and who investigates.

Ask the developer to recommend the connection and refresh approach against those needs. Confirm any gateway, credentials, capacity and licensing dependencies; feasible behaviour varies by configuration, as Microsoft’s data refresh guidance explains. Request frequent updates only where the decision needs them.

07 / Validation and sign-off

Agree what will count as accepted

Acceptance criteria should describe evidence, expected results and an approver. “The report looks right” is too subjective to close a project confidently.

• Accuracy: reconcile agreed periods and entities to approved source totals, with an explicit tolerance and explained differences.
• Business rules: check blanks, duplicates, cancelled transactions, reopened items and period boundaries.
• Usability: representative users complete the priority tasks with the intended filters and navigation.
• Security and operation: test permitted and denied access, refresh completion and failure handling.
• Performance: agree response-time targets using specified data volumes, devices and realistic user conditions.

Name the people performing user acceptance testing, their available review dates and the person authorised to sign off. Record defects and distinguish fixes from new requirements. Agree how unresolved issues affect release.

08 / Ownership after launch

Include handover in the scope

Identify the business owner and technical support owner. Specify the editable report and model files, measure definitions, source mappings, access rules and refresh instructions your team needs to maintain the solution.

Include training, administrator handover, credential ownership, a support period and a route for future changes. Confirm who handles source-system changes or new KPIs. Set a review date to check whether people use the report and whether it supports the intended decisions.

An illustrative brief

From a broad request to a useful requirement

The following is a fictional finance and procurement example, not a client result.

The next discussion can resolve data quality, page layouts, performance targets, budget and milestones. It starts from a shared business requirement.

Your starting point

Copyable Power BI briefing checklist

Select and copy the text below into your project brief. Fill in the answers and mark unknowns with an owner and a date for resolution.

POWER BI DEVELOPMENT BRIEF

[ ] Business purpose and decisions this will support:
[ ] Users, team sizes, report owner and sign-off owner:
[ ] First-release priorities and explicit exclusions:
[ ] KPIs: definition, formula, unit, period, exclusions and owner:
[ ] Targets, thresholds and action when a measure changes:
[ ] Data sources, owners, access and representative samples:
[ ] Data grain, history, joins and known quality issues:
[ ] Responsibility and timing for data fixes:
[ ] Deliverables: report pages, service dashboard or both:
[ ] Layouts, filters, drill-through, mobile and export needs:
[ ] User groups, permitted data and RLS test scenarios:
[ ] Workspace, distribution method and licence assumptions:
[ ] Source cut-off, freshness deadline, refresh and time zone:
[ ] Gateway, credentials, monitoring and failure owner:
[ ] Reconciliation totals, tolerances and edge-case tests:
[ ] User tasks, response-time targets and test conditions:
[ ] Acceptance evidence, approvers and defect process:
[ ] Documentation, source files, training and handover:
[ ] Ongoing support, change ownership and review date:
[ ] Budget, milestones, dependencies and open questions:

Use the completed brief to ask each delivery partner to state assumptions, exclusions, dependencies and acceptance evidence in its proposal. This makes the conversation about a usable reporting solution, with a clear basis for delivery.