Power BI Business Analysis

This is Phase 1 of the agent pipeline. Analyze the business request and produce a Requirements Document that becomes the handoff contract to Phase 2 (Semantic Model).

The skill itself runs as four internal Steps (to avoid colliding with the agent's own Phase numbering):

Step 1 ── Step 2 ── Step 3 ── Step 4
CONTEXT   DOMAIN    INFO-ARCH OUTPUT
(WHO/     (KPIs by  (page     (Requirements
 WHAT/    industry)  plan)     Document +
 HOW)                          handoff JSON)

Always search Microsoft Learn (microsoft-learn-mcp/microsoftdocssearch) for domain-specific Power BI guidance and best practices before making recommendations.

Useful research queries

Run these at the start of each step, replacing <domain> with the business domain:

Use microsoftdocsfetch to read full articles when excerpts are insufficient.

Reference Files (read in this order)

When to Use This Skill vs. Others

Both this skill and power-bi-report-design handle "dashboard planning" — but this skill stops at the page plan; power-bi-report-design turns that plan into a Design Spec with specific layouts, recipes, and themes.

Step 1 — Context Assessment (WHO / WHAT / HOW)

Before touching any data, run the stakeholder interview.

→ Read [stakeholder-interview-template.md](references/stakeholder-interview-template.md) and record answers verbatim in the table at the bottom of that file.

The three question groups map to:

WHO is the audience?

Map the interview answers (questions 1–5) to a report archetype:

Using the data-literacy score (interview Q5):

• 1–2 (prefer summary) → fewer slicers, larger fonts, more narrative titles, Big-Idea phrasing over raw numbers
• 3 (neutral) → default Analytical archetype
• 4–5 (writes SQL) → add detail tables, export buttons, richer slicer panel, expose grain

WHAT decisions will this support?

Use interview answers 6–10 to capture:

• The one question the report must answer (→ Big-Idea title in §1 of the Requirements Document)
• The action the user takes after viewing (→ validates the report drives action, not just awareness)
• Comparisons that matter (→ time-intelligence measures in Step 2)
• Success criteria (→ UAT acceptance criteria in Phase 6)

HOW does data support the story?

Use interview answers 11–15 to capture:

• Data sources, lowest grain, history depth, access restrictions, constraints
• These feed directly into Step 3's Data Gap Analysis and the Phase 2 storage-mode decision

Skip Step 1 when…

• User provides a complete brief in one message (domain + KPIs + page plan) → go to Step 2 with their brief as input
• Model already exists AND has ≤ 5 measures AND user describes ≤ 3 pages → Express Path: condense Steps 1–3 into a single model-discovery pass (see agent.md §Express Path)

Step 2 — Domain Analysis

Identify standard KPIs and analyses for the domain.

→ Read [domain-kpi-templates.md](references/domain-kpi-templates.md) — find the matching section for your domain and lift the KPI table, dimensions, and analyses.

Domains covered: Sales & Revenue, FMCG, Manufacturing, Supply Chain, Financial/P&L, Retail, Procurement, Healthcare/Pharma, Technology/IT. Customize based on stakeholder interview answers (questions 8–10).

Storytelling principles (pre-attentive attributes, narrative structure) live in the power-bi-report-design skill at [visual-design-principles.md](../power-bi-report-design/references/visual-design-principles.md) — do not duplicate them here.

Step 3 — Information Architecture & Data Gaps

Design the report structure and verify the data exists to support it.

→ Read [information-architecture-patterns.md](references/information-architecture-patterns.md) for archetype-specific page flows, canvas sizing, and navigation patterns.

Page plan

→ Read [information-architecture-patterns.md](references/information-architecture-patterns.md) for the universal 4-layer progression and archetype-specific page flows.

Minimum viable report = Overview (Layer 1) + Detail drillthrough (Layer 3). Full analytical report = all four layers (Overview → Analysis → Detail → Tooltip). For archetype-specific page counts and flows, use the reference file's diagrams.

Filter requirements (not design)

At Phase 1, capture which dimensions need to be filterable and who can see what (RLS). Do not decide slicer types, placement, sync groups, or cross-filter behavior — those are Phase 4a design decisions owned by the power-bi-report-design skill.

In [Requirements Document §6](references/requirements-document-template.md), list:

• Dimensions the audience must be able to filter by (Date, Region, Product, etc.)
• Whether each filter is required (must-have) or nice-to-have
• Expected scope hints (e.g. "Date is global", "Promotion only on the Promotion page")
• RLS requirements go in §7 (role, scoped column, rule expression)

Data gap analysis

Before finalizing the page plan, verify every KPI has a data source.

→ Read [data-gap-analysis-template.md](references/data-gap-analysis-template.md) and fill its requirements-vs-data matrix.

Each KPI ends up in one of three states:

• ✅ Available — data exists at the right grain → proceed
• ⚠️ Partial — needs transformation, different grain, or incomplete history → document ETL work in §4 of the Requirements Document
• ❌ Missing — no source → escalate, defer to backlog, or drop from v1

Gaps marked ❌ that block must-have KPIs are blockers for Phase 2 — do not produce a handoff until they have a resolution plan.

Step 4 — Output: Requirements Document + Handoff

Produce the formal deliverable.

→ Use [requirements-document-template.md](references/requirements-document-template.md) as the structure. Fill all 10 sections (mark N/A where appropriate for Express Path).

The template's §5 Measure Inventory is the direct input to the power-bi-dax-development skill — name each measure, its pattern, dependencies, and priority.

Note: For quick iterations, measures and relationships can be edited directly in the Power BI Service (web). Only complex model changes (partitions, M queries, custom columns with complex logic) require Desktop. Specify which changes can be service-side for faster turnaround.

Handoff to Phase 2

The Phase 1 → Phase 2 transition passes the following artifacts:

The agent validates completeness before proceeding to Phase 2.

Exit Criteria — done when…

Phase 1 is complete when every item below is true:

• Requirements Document exists with all 10 sections filled (or marked N/A)
• Audience archetype selected (Executive / Analytical / Operational / Exploration)
• KPI list is complete, with business definitions and priority (Must / Should / Nice)
• Page plan has Overview + at least one Analysis page + Detail page
• Measures Inventory lists every measure with owner table and DAX pattern
• Required filter dimensions listed in §6 (design handled later in Phase 4a)
• Data Gap Analysis complete — no unresolved ❌ blockers on must-have KPIs
• Handoff JSON validates against the schema
• User has approved the Requirements Document

Do not proceed to Phase 2 until the user approves. If they request changes, iterate within Step 4.

Worked Example

→ Read [worked-example-fmcg.md](references/worked-example-fmcg.md) for a complete trace of the four Steps applied to a realistic FMCG Trade Analytics brief.

Related Skills

Anti-Patterns to Avoid