| name | power-bi-business-analysis |
| description | Analyze business requirements and define BI strategy for Power BI projects. Use this skill whenever the user wants to analyze business requirements, identify KPIs, define what insights a report should deliver, propose dashboard structure for a business domain, or gather requirements before building a Power BI report or semantic model. Triggers include: "analyze business requirements", "what KPIs should we track", "what insights can we get", "business domain analysis", "requirements gathering", "what should we measure", "what problems can we solve", "propose a dashboard", "what reports do we need", "BI strategy", "define metrics". Do NOT use for actual model building (use power-bi-semantic-model), DAX writing (use power-bi-dax-development), or report generation (use power-bi-report-authoring). |
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/microsoft_docs_search) 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:
| Step | Sample query |
|---|
| Step 1 | Power BI report archetype executive analytical operational |
| Step 2 | Power BI <domain> KPI best practices dashboard examples |
| Step 2 | DAX time intelligence year-over-year pattern |
| Step 3 | Power BI drillthrough tooltip page design guidelines |
| Step 3 | Power BI semantic model data source <source-type> limitations |
| Step 4 | Power BI row-level security RLS static dynamic patterns |
Use microsoft_docs_fetch to read full articles when excerpts are insufficient.
Reference Files (read in this order)
When to Use This Skill vs. Others
| Say this → | Use this skill |
|---|
| "what should we measure", "define KPIs", "gather requirements" | power-bi-business-analysis (this skill) |
| "design the layout", "choose chart types", "pick a theme" | power-bi-report-design |
| "build the model", "create tables", "set up relationships" | power-bi-semantic-model |
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
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:
| Audience | Report Archetype | Characteristics |
|---|
| C-suite / executives | Executive | 3-5 KPI cards, trend lines, exception alerts, minimal detail |
| Department managers | Analytical | Drill-down, period comparisons, target vs actual, filters |
| Analysts | Exploration | Many slicers, detail tables, export capability, multiple views |
| Operators / field staff | Operational | Real-time status, action items, mobile-optimized, alerts |
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 — 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
— 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
for archetype-specific page flows, canvas sizing, and navigation patterns.
Page plan
→ Read 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, 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
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
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:
| Key | Source |
|---|
requirements_document | Requirements Document §1–§8 |
measures_inventory | Requirements Document §5 |
page_plan | Requirements Document §3 |
data_source_list | Requirements Document §4 + gap analysis results |
The agent validates completeness before proceeding to Phase 2.
Exit Criteria — done when…
Phase 1 is complete when every item below is true:
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 for a complete
trace of the four Steps applied to a realistic FMCG Trade Analytics brief.
Related Skills
| Skill | Relationship | When it receives output from this skill |
|---|
power-bi-semantic-model | Downstream (Phase 2) | §3 page plan + §4 data requirements drive table + relationship design |
power-bi-dax-development | Downstream (Phase 3) | §5 Measure Inventory is the measure build list |
power-bi-report-design | Downstream (Phase 4a) | Archetype + page plan + audience feed the Design Spec |
power-bi-feedback-iteration | Loop-back | "Missing insight" / "new requirement" feedback routes back to Step 1 or 2 |
Anti-Patterns to Avoid
| ❌ Don't | ✅ Do instead |
|---|
| Start with visuals before understanding the business question | Complete Step 1 (WHO/WHAT/HOW) first |
| Measure everything the data allows | Filter to KPIs the user confirmed in interview Q10 |
| Build "vanity metrics" that look impressive | Tie each KPI to a decision (interview Q7) |
| Create one report for all audiences | One archetype per report; split if stakeholders disagree |
| Present numbers without a "so what" | Every page has a Big-Idea title (interview Q6) |
| Cram every question into one report | Defer to backlog; one report = one focused narrative |
| Skip the data gap analysis | Run it before promising KPIs to the user |
