Skip to content
Henry Rincón
CV (PDF)

Methods · Topic T7

How a BI solution people actually use should be designed

It prints in full from the browser, on A4 or Letter.

Block 1

The problem

Designing a semantic model and the dashboards built on it so that whoever decides actually uses them: comes back to them in every decision cycle, trusts every figure and never has to ask how it was calculated.

Summary in three lines

  1. The starting point is the decision, not the data available: who decides, how often and what action follows a figure. Adoption is framed as a design hypothesis from the start and validated in operation; sometimes the answer is not a dashboard but an alert, an application or a model.
  2. Meaning lives in the Power BI semantic model: a star schema with its grain declared, all preparation in Power Query and every indicator as a single DAX measure, with its agreed definition and its owner. Row-level security and the storage mode are decided at design time, not at publishing time.
  3. No figure is published without a control that can fail —an independent baseline, identities that close, an external reconciliation—, and after publishing, adoption is measured with signals of real use, not with visits; whatever lost its purpose is retired.
Block 2

The map

From the decision to the semantic model, and from the published dashboard to measured adoption

Swipe to see the whole map.

From the decision to the semantic model, and from the published dashboard to measured adoptionEverything starts with a decision and whoever makes it: that decision calls for sources whose provenance is kept. Power Query prepares them before the first measure, and an independent baseline reads the raw files to predict what the model has to load. The star schema, with its grain declared, holds one DAX measure per indicator; those measures feed a dashboard written as code and are also read by applications and agents, instead of reinterpreting the table. Whoever uses the dashboard sees it filtered by row-level security and learns to read it through training on their own products. Real use leaves adoption signals; that evidence decides whether the product is improved, merged or retired, and what is learned goes back to the decision.The decision andits owner1Sources withprovenance2Preparation inPower Query3Star schema,grain4Agreed DAXmeasures5Report as code6Independentbaseline7Applications andagents8Row-levelsecurity9Whoever uses thedashboard10Improve, merge orretire11Adoption signals12Training on theirown products13

Legend of shapes and colors

  • Actor — who does the work
  • Data — what is stored and read
  • Control — a rule that gets checked
  • Person — a person decides
  • External — what comes from outside

Reading the map, node by node

Everything starts with a decision and whoever makes it: that decision calls for sources whose provenance is kept. Power Query prepares them before the first measure, and an independent baseline reads the raw files to predict what the model has to load. The star schema, with its grain declared, holds one DAX measure per indicator; those measures feed a dashboard written as code and are also read by applications and agents, instead of reinterpreting the table. Whoever uses the dashboard sees it filtered by row-level security and learns to read it through training on their own products. Real use leaves adoption signals; that evidence decides whether the product is improved, merged or retired, and what is learned goes back to the decision.

  1. Node 1 The decision and its owner (Person) — Who decides, how often and what action follows the figure: the starting point of the design.
  2. Node 2 Sources with provenance (External) — Every file with its publisher, its period and its download date, so the path of every figure can be rebuilt.
  3. Node 3 Preparation in Power Query (Control) — All transformation before the first measure: types, duplicates, missing values and de-accumulation, visible and versioned.
  4. Node 4 Star schema, grain (Data) — Dimensions to filter and group, facts to summarize, and the grain of every fact table written down before the first measure.
  5. Node 5 Agreed DAX measures (Data) — Every indicator with an agreed definition, an owner and a calculation rule that every report reuses.
  6. Node 6 Report as code (Data) — Pages and visuals generated from a single set of measures, versioned and reviewable like any other change.
  7. Node 7 Independent baseline (Control) — A separate script predicts counts and control figures from the raw files, before the model is refreshed.
  8. Node 8 Applications and agents (Actor) — New consumers: they read the governed measure instead of rebuilding the metric on their own.
  9. Node 9 Row-level security (Control) — Filters on the dimensions, tested by impersonating every role before publishing.
  10. Node 10 Whoever uses the dashboard (Person) — Each audience reads the same figure at the depth its responsibility calls for.
  11. Node 11 Improve, merge or retire (Control) — Every requested change is weighed against the product’s purpose; whatever lost its purpose is retired.
  12. Node 12 Adoption signals (Control) — Recurrence, depth of use, substitution, conversation, action and outcome: real use, not visits.
  13. Node 13 Training on their own products (Person) — Whoever uses the dashboard learns to read the measure, to question it and to ask the next question.

Connections

  • from The decision and its owner to Sources with provenance (calls for)
  • from Sources with provenance to Preparation in Power Query
  • from Sources with provenance to Independent baseline (raw)
  • from Preparation in Power Query to Star schema, grain (loads)
  • from Independent baseline to Star schema, grain (predicts)
  • from Star schema, grain to Agreed DAX measures
  • from Agreed DAX measures to Report as code (feeds)
  • from Agreed DAX measures to Applications and agents (read it)
  • from Report as code to Whoever uses the dashboard (shows)
  • from Row-level security to Whoever uses the dashboard (filters)
  • from Training on their own products to Whoever uses the dashboard (trains)
  • from Whoever uses the dashboard to Adoption signals (real use)
  • from Adoption signals to Improve, merge or retire (evidence)
  • from Improve, merge or retire to The decision and its owner (back to the decision)
Block 3

The phases

  1. Phase 1

    Start from the decision and whoever makes it

    Inputs

    • The process and the decisions the data must support.
    • The audiences and what each one already uses to decide.

    Activities

    • Identify who decides, how often, what information they use today and how long that information keeps its value.
    • Choose the instrument: a dashboard to explore and compare; an alert, an application or a model when the decision calls for something else.
    • Write the expected adoption down as a hypothesis: who will use it, for which decision and how often.

    Artifacts

    • The decision sheet: audience, frequency and action.
    • The adoption hypothesis.
    Who decides
    The process owner.
    Control that closes the phase
    If nobody can name the decision the dashboard supports, the dashboard is not built.
    Evidence

    At Fundación CTIC each of the more than 25 analytics products is born from a process leader’s question and not from an available table; that is why it can be stated that some 20 leaders of some 15 processes use them, and not merely that they are published.

  2. Phase 2

    Prepare the data in Power Query, with its provenance

    Inputs

    • The sources and their documentation.
    • The known traps of each source.

    Activities

    • Keep the file, the period, the publisher and the download date of every source.
    • Separate connecting, preparing and building the model’s tables, and resolve types, duplicates, missing values and accumulations before the first measure.
    • Run an independent baseline that predicts from the raw files the counts and control figures the model has to load.

    Artifacts

    • The Power Query queries, versioned.
    • The baseline with its predictions.
    Who decides
    Whoever answers for the model.
    Control that closes the phase
    The count the model loads matches the one the baseline predicted; an unexplained difference stops the refresh.
    Evidence

    In the public spending dashboard, the Python baseline over the raw files caught, by arithmetic, a de-accumulation that was losing two out of every three pesos —19 rows per series where only 12 months fit— before it reached Power BI.

  3. Phase 3

    Design the semantic model in Power BI: star schema, grain and DAX measures

    Inputs

    • The prepared tables.
    • The definitions agreed with the business.

    Activities

    • Set the unit of analysis and the grain of every fact table before writing a measure.
    • Separate the dimensions, which filter and group, from the facts, which get summarized, with one-to-many relationships.
    • Write every indicator as an explicit DAX measure, with no calculated columns, with its definition and its owner.
    • Do not relate two fact tables whose scopes or keys do not match: they are conformed only through the dimensions they share.

    Artifacts

    • The star schema.
    • The catalog of measures, each one with its definition and its owner.
    Who decides
    The business agrees on the definition; the model turns it into a rule.
    Control that closes the phase
    The identities the source guarantees close over the full universe, not over a sample.
    State of the field

    Microsoft asks for every model table to be either a dimension or a fact table, without mixing the two, and for every fact table to always load data at a consistent grain: dimensions filter and group, facts summarize.[1]

  4. Phase 4

    Secure, verify and measure performance before publishing

    Inputs

    • The semantic model with its measures.
    • Who can see what.

    Activities

    • Define row-level security on the dimensions and test every role by impersonating it.
    • Choose the storage mode by the freshness, volume and cost each use calls for.
    • Measure costly queries and measures with DAX Studio before and after every adjustment, and organize the model with Tabular Editor.
    • Reconcile the control figure against an external source, when there is one.

    Artifacts

    • The tested roles.
    • The before-and-after measurements.
    Who decides
    Whoever answers for the model.
    Control that closes the phase
    A role that was not tested by impersonating it is not published, and a slow measure is fixed before the audience suffers it.
    Evidence

    At Banco Pichincha, in 2023, DAX Studio served to identify costly calculations and compare before and after every adjustment, and Tabular Editor to organize the semantic models used by more than 50 users.

  5. Phase 5

    Write the dashboard as code and version it

    Inputs

    • The verified model.
    • The palette, the texts and the hierarchy of the decision.

    Activities

    • Generate the pages and visuals from a single set of measures, following the visual hierarchy of the decision.
    • Validate before opening Power BI: field references, palette colors and texts that fit their box.
    • Version the model and the report in Git, and keep the human review of the render as the last layer.

    Artifacts

    • The versioned project, with the report and the model as text.
    • The validator and its result.
    Who decides
    Whoever approves the render.
    Control that closes the phase
    No dashboard is published with a broken reference between report and model or without a human review of the render.
    Evidence

    In the six open-data dashboards, the PBIR report is written with Python from a single set of measures, with a script that fails on an orphan color, a broken link or an untranslated text; in energy and climate, 0 of 354 references between report and model were broken.

  6. Phase 6

    Train, observe use and retire what lost its purpose

    Inputs

    • The published dashboard and its audience.
    • The adoption hypothesis.

    Activities

    • Train on each audience’s own products, at the depth its responsibility calls for.
    • Observe who uses the product, which questions come up and where there is friction.
    • Weigh every requested change against the product’s purpose and retire whatever stopped adding value, telling its users.

    Artifacts

    • The training program.
    • The reading of the adoption signals and the decision to improve, merge or retire.
    Who decides
    The process owner, together with whoever answers for the analytics portfolio.
    Control that closes the phase
    Before a new product, the question is whether it fits on a model that already exists.
    Evidence

    At Banco Pichincha the training was designed together with the dashboards, for 12 professionals and on their own products, and it contributed to a 20% improvement in productivity when preparing and using information.

Block 4

The design decisions

  1. Semantic model design in Power BI: star schema and declared grain

    When yes
    Whenever there are facts to summarize and entities to filter: the Power BI semantic model puts dimensions on one side, facts on the other and every fact table at a consistent grain.
    When no
    A flat table copied from the source system, or two facts related to each other when their scopes or keys do not match: there the honest relationship is none.

    Why

    Evidence

    The six open-data dashboards are star schemas —16 tables in banking, 25 in Formula 1—, and in banking the four facts are not related to each other because they have different scopes.

    Judgment

    In semantic model design, the grain is written down before the first measure: a relationship between different grains duplicates figures that still look plausible.

  2. Explicit DAX measures and preparation in Power Query, with no calculated columns

    When yes
    Every row transformation goes to Power Query, where it is seen, versioned and tested; DAX keeps what depends on filter context: the measures.
    When no
    A calculated column only when the formula needs to evaluate measures or a function that exists only in DAX, such as those for parent-child hierarchies.

    Why

    Evidence

    None of the six open-data dashboards has a calculated column: they add up to 329 DAX measures, and the preparation —24 queries in the monetary cycle, 33 in Formula 1— lives in Power Query.

    State of the field

    Microsoft explains that a DAX calculated column typically compresses less efficiently and is built after all tables load, which is why it prefers a Power Query custom column.[2]

  3. Import, Direct Lake or DirectQuery, and the row-level security trap

    When yes
    Import when the volume fits in memory and the figure must be stable; Direct Lake on OneLake when the data already lives in Delta tables and must be seen right away.
    When no
    Direct Lake on the SQL analytics endpoint when that endpoint enforces row-level security: the query stops reading from memory and gets slower.

    Why

    Evidence

    At Vesting the models combined Direct Lake, import and DirectQuery depending on use; the six open-data dashboards use import, which, with 6.4 million fact rows in the largest of them, sustains it without difficulty.

    State of the field

    With Direct Lake on the SQL analytics endpoint, a table with row-level security defined in SQL makes the query fall back to DirectQuery, or fail if that fallback is disabled; Direct Lake on OneLake does not apply that SQL security, and for the model’s row-level security Microsoft recommends a fixed-identity connection.[3][4]

  4. Row-level security in a single model or a model per audience

    When yes
    A single model with row-level security when the audiences share the definitions and only what each one can see changes.
    When no
    Only a filter when the boundary cannot depend on the filter being well written: then the workspaces are separated.

    Why

    Evidence

    At Vesting row-level security was defined as DAX filters on the dimension tables and tested by impersonating roles before publishing; across the 12 clients, isolation also ran through separate workspaces.

    State of the field

    Microsoft advises enforcing the filters on dimension tables rather than fact tables, testing every role with “View as” —with dynamic rules, against unexpected values too— and warns that row-level security only restricts those with the Viewer role in the workspace.[5][6]

  5. The dashboard written as code or built by hand

    When yes
    As code when there are several pages, two languages or dashboards that repeat: the design stays in files that can be read, compared and regenerated.
    When no
    By hand when it is a single, exploratory piece still looking for its question.

    Why

    Evidence

    The twelve pages of each open-data dashboard —six in Spanish and six in English— come out of the same model and the same set of measures, and the visuals —142 in companies, 112 in energy, 78 in Formula 1— are generated with Python.

    Evidence

    The Power BI Dashboard Builder takes the same principle to an agent: it creates every measure through the modeling MCP server, testing it in DAX before moving on, and writes the report in Power BI’s native JSON.

  6. How to measure the adoption of a dashboard: real use or visits

    When yes
    To measure the adoption of a dashboard: signals of real use —recurrence, depth of use, substitution of files and reconciliations, conversation, action and outcome—, with every figure on its rung: access, use, adoption or impact.
    When no
    Counting visits or access as adoption: a visit can be curiosity, a one-off check or an instruction received.

    Why

    Evidence

    At Banco Pichincha “more than 50 users” is adoption and the +25% in decision-making is impact; at Fundación CTIC, “some 20 leaders of some 15 processes” is counted adoption and the “close to 60%” is an estimate, which is why it carries the “close to”.

    State of the field

    Microsoft’s adoption roadmap warns that usage statistics alone don’t indicate successful user adoption, and the Power BI usage metrics report, in preview, counts views, unique viewers and opening times.[17][19]

Block 5

What is new in 2026

  • State of the field

    Copilot and Fabric data agents read the semantic model

    What changes from common practice

    Copilot in Power BI uses what is saved in the semantic model with “Prep data for AI” (in preview) —a data schema, verified answers and instructions, saved on the model and not on the report— and requires a workspace on a paid Fabric capacity (F2 or higher), on a Premium one (P1 or higher) or on a Fabric Copilot capacity; a Fabric data agent queries semantic models by generating DAX, read-only and with the permissions of whoever asks.[14][15][16]

    Judgment

    What an assistant answers depends on the measure it reads: an indicator with two definitions gives it two answers too.

  • State of the field

    Q&A, the legacy natural-language tool, is deprecated in December 2026

    What changes from common practice

    In its January 2026 update, Microsoft announced that Q&A is deprecated in December 2026 and pointed to Copilot for querying data in natural language.[20]

    Judgment

    An announced retirement is a work date: the dashboards that depend on what is being retired are inventoried before, not after.

  • State of the field

    PBIR and PBIP: the report and the model as versionable text

    What changes from common practice

    A Power BI project saves the report and the semantic model as text files ready for Git and for programmatic generation; the PBIR report format is now the default, saves every page and every visual in a JSON file with a public schema, and Power BI converts a legacy report when it is edited and saved.[10][11]

    Evidence

    The six open-data dashboards are published as a versioned project, with the PBIR report written by Python: reviewing a page is reviewing a change.

  • State of the field

    An MCP server to author the semantic model

    What changes from common practice

    The Power BI Authoring MCP server —local, generally available, and hosted, in preview— lets an agent create tables, measures, relationships, calculation groups and security roles, and run DAX to validate the model while building it; Microsoft advises working on PBIP files under Git to review every change the agent makes before committing it and to be able to revert it.[12][13]

    Evidence

    The Power BI Dashboard Builder proposes the list of measures, columns and relationships for a person to approve, creates them through the modeling MCP server testing every measure in DAX, and delivers a versioned local project.

  • State of the field

    Fewer repeated measures: calculation groups, user-defined functions and visual calculations

    What changes from common practice

    Calculation groups apply the same pattern —prior year, year to date— to any explicit measure; DAX user-defined functions, generally available since the June 2026 release, package parameterized logic that is reused in measures, columns and visual calculations; and visual calculations operate on what is already in the visual, with templates such as the running sum or the comparison with the previous value.[7][8][9]

    Evidence

    At Banco Pichincha every new measure went through one question: whether there was already one doing the same thing under another name.

  • State of the field

    Adoption at three levels: organization, user and solution

    What changes from common practice

    The Fabric adoption roadmap separates organizational adoption, the adoption of each user —from awareness to proficiency— and the adoption of a solution, which becomes “essential” when its users actively and routinely use it to decide; Power BI planning asks for defining the objectives, the behaviors that sustain them and the indicators that measure them, reviewed at a consistent cadence.[17][18]

    Evidence

    At Fundación CTIC observation after publishing has a shape: some ten analysis plans under follow-up on the more than 25 products.

Block 6

Failure modes and how to anticipate them

  • What breaks
    A correct dashboard nobody opens again
    How it shows up
    Only those who built it look at it, and meetings still start from a separate file.
    Control that catches it
    Design from the decision and adoption written down as a hypothesis from the start, validated in operation.
  • What breaks
    Two figures for the same indicator
    How it shows up
    Every meeting starts by arguing about which number is right.
    Control that catches it
    A single measure per indicator in the semantic model, with its agreed definition and its owner.
  • What breaks
    A relationship between different grains duplicates totals
    How it shows up
    Plausible totals that do not close against the source, in a dashboard that keeps working.
    Control that catches it
    The grain written down per fact table and the source identities run over the full universe.
  • What breaks
    A transformation hidden in a calculated column
    How it shows up
    A figure changes and nobody can find where it was transformed.
    Control that catches it
    All preparation in Power Query, versioned; no calculated column without a reason only DAX can solve.
  • What breaks
    Row-level security does not reach whoever edits
    How it shows up
    Someone with a member or contributor role in the workspace sees rows their security role would not give them.
    Control that catches it
    Whoever consumes, with the Viewer role; every role, tested by impersonating it before publishing.
  • What breaks
    Direct Lake falls back to DirectQuery when row-level security is at the SQL analytics endpoint
    How it shows up
    The dashboard slows down exactly on the tables with row-level security defined at the SQL analytics endpoint.
    Control that catches it
    Direct Lake on OneLake for new models, or the security in the model with a fixed identity, and the fallback watched.
  • What breaks
    A slow measure drives the audience away
    How it shows up
    Seconds of waiting multiplied by every person who opens the dashboard.
    Control that catches it
    Costly measures timed with DAX Studio before and after every adjustment, before publishing.
  • What breaks
    The portfolio grows and fragments attention
    How it shows up
    Dashboards that repeat indicators and compete for the same question.
    Control that catches it
    Before a new product: extend an existing model, simplify or retire.
Block 7

Metrics and controls

  • What is measured
    Adoption by audience
    Threshold
    Every target audience comes back to the dashboard in every decision cycle that justifies it; it is counted by role, not by access.
    Who approves the step to production
    The process owner.
  • What is measured
    Indicators with one definition and one owner
    Threshold
    All of those used by more than one report.
    Who approves the step to production
    The business owner.
  • What is measured
    Counts and control figures against the baseline
    Threshold
    All of them match before the refresh; an unexplained difference stops publishing.
    Who approves the step to production
    Whoever answers for the model.
  • What is measured
    Source identities
    Threshold
    They close over the full universe; the one that does not close is explained or published as a limit.
    Who approves the step to production
    Whoever answers for the model.
  • What is measured
    Security roles tested
    Threshold
    All of them, impersonating every role before publishing.
    Who approves the step to production
    Whoever answers for the data.
  • What is measured
    Response time of critical measures
    Threshold
    Measured before and after every change; no regression without an explanation.
    Who approves the step to production
    Whoever answers for the model.
  • What is measured
    References between report and model
    Threshold
    None broken before opening Power BI.
    Who approves the step to production
    Whoever builds the dashboard.
  • What is measured
    Products without use
    Threshold
    Reviewed every cycle: they either regain their purpose or are retired.
    Who approves the step to production
    Whoever answers for the analytics portfolio.

The thresholds are examples of the method, not figures from a specific project.

Block 8

Evidence from projects

  • EvidenceLevel: Real use

    Banco Pichincha: dashboards the business did use

    Between March and July 2023, a business intelligence team of 5 people developed and strengthened Power BI dashboards used by more than 50 business users, with a reported 25% improvement in decision-making; the ETL in Power Query cut analysis times by 35% and the semantic models were optimized with DAX Studio and Tabular Editor.

    See where
  • EvidenceLevel: Real use

    Banco Pichincha: training as part of the product

    A program designed together with the dashboards, for 12 professionals and on their own products —Power Query, semantic modeling, DAX and executive communication—, contributed to a 20% improvement in productivity when preparing and using information.

    See where
  • EvidenceLevel: Real use

    TransMilenio: Power BI in post-operational analysis

    Between July 2021 and May 2022, at C&M Consultores, Power BI was adopted by more than 25 key users —people responsible for scheduling, monitoring and decisions, not merely people with access— and contributed to a 35% improvement in the efficiency of analytical processes; every figure could be traced back to the source that produced it.

    See where
  • EvidenceLevel: Real use

    Cafam: a control BI adopted by role

    Between October 2020 and June 2021, the control BI for the Oracle WMS Cloud implementation at a medicine distribution center was adopted by more than 15 users with a title —directors, coordinators and heads— and improved the accuracy of test tracking by 50%.

    See where
  • EvidenceLevel: Real use

    Fundación CTIC: analytics products by process

    Since March 2025, more than 25 analytics products in Power BI —control dashboards among them— are used by some 20 leaders of some 15 processes and some 75 users, administrative and clinical; every indicator keeps one institutional definition and each audience reads it at the depth of its responsibility. The effect is declared as an estimate: close to 60% less preparation effort.

    See where
  • EvidenceLevel: Real use

    The six open-data dashboards

    Six dashboards on public sources, sealed in September 2026 after seven build phases each: star schemas, 329 DAX measures and no calculated columns; an independent Python baseline before every refresh and coverage published as a figure, such as 84.9% of the ranking of the ten thousand largest companies.

    See where
  • EvidenceLevel: Real use

    Las empresas de Colombia en cifras: composition bias, corrected

    The aggregate said 2020 fell 2.2%; over the same 23,321 companies present in both years, the contraction was 7.4%. That is why the dashboard never shows aggregate growth alone: next to it goes the growth of the same companies, on the same axis.

    See where
  • EvidenceLevel: Real use

    Power BI Dashboard Builder (Constructor de Tableros Power BI)

    An agent built and tested that, from a requirements text and a project with the tables, produces the complete .pbip project —semantic model, Power Query M, DAX measures and visuals in the report’s native JSON—; a run is accepted against 20 binary criteria, goes through 5 human approval gates and does not close without a person approving the render in Power BI Desktop.

    See where
  • EvidenceLevel: Real use

    Vesting: storage modes and row-level security on Fabric

    On Microsoft Fabric, the models combined Direct Lake for operational monitoring, import for the history and DirectQuery to drill down to a session’s events; row-level security was defined with DAX filters on the dimension tables and tested by impersonating roles before publishing.

    See where
Block 9

Limits and scope

  • Evidence

    The six open-data dashboards do not use Microsoft Fabric: they are desktop pieces in import mode, published as a versioned project, and their data is a dated snapshot that does not update on its own.

  • Evidence

    On the author’s profile, Shiny, Tableau and Looker Studio do not occupy the same level as Power BI and Microsoft Fabric.

  • Evidence

    Copilot in Power BI and Fabric data agents appear here as the state of the field: the evidence of an agent working on a semantic model is the Power BI Dashboard Builder, which does it with no Fabric ecosystem, builds from scratch, delivers a versioned local project and does not publish to the cloud service.

  • Evidence

    In the Power BI Dashboard Builder, the hours saved that justify its existence are an estimate declared as such: no run has yet been timed against the baseline of a dashboard built by hand.

  • Evidence

    At Fundación CTIC the figures are published aggregated and approximate, and the close to 60% less effort is an estimate on the author’s own work, not an institutional measurement.

  • Judgment

    What should be done differently today: prepare the model for Copilot —schema, verified answers and instructions— as part of designing the model, not as an afterthought.

  • Judgment

    A dashboard nobody opens is not fixed with another visual: the work goes back to the decision it was meant to support.

Block 10

Sources and review date

  1. [1]
    Understand star schema and the importance for Power BI

    Microsoft Learn ·

    https://learn.microsoft.com/en-us/power-bi/guidance/star-schema

  2. [2]
    Data reduction techniques for Import modeling

    Microsoft Learn ·

    https://learn.microsoft.com/en-us/power-bi/guidance/import-modeling-data-reduction

  3. [3]
    Direct Lake overview

    Microsoft Learn ·

    https://learn.microsoft.com/en-us/fabric/fundamentals/direct-lake-overview

  4. [4]
    Integrate Direct Lake security

    Microsoft Learn ·

    https://learn.microsoft.com/en-us/fabric/fundamentals/direct-lake-security-integration

  5. [5]
    Row-level security (RLS) guidance in Power BI Desktop

    Microsoft Learn ·

    https://learn.microsoft.com/en-us/power-bi/guidance/rls-guidance

  6. [6]
    Row-level security (RLS) with Power BI

    Microsoft Learn ·

    https://learn.microsoft.com/en-us/fabric/security/service-admin-row-level-security

  7. [7]
    Create calculation groups

    Microsoft Learn ·

    https://learn.microsoft.com/en-us/power-bi/transform-model/calculation-groups

  8. [8]
    Visual calculations

    Microsoft Learn ·

    https://learn.microsoft.com/en-us/power-bi/transform-model/desktop-visual-calculations-overview

  9. [9]
    DAX user-defined functions

    Microsoft Learn ·

    https://learn.microsoft.com/en-us/power-bi/transform-model/desktop-user-defined-functions-overview

  10. [10]
    Power BI Desktop projects

    Microsoft Learn ·

    https://learn.microsoft.com/en-us/power-bi/developer/projects/projects-overview

  11. [11]
    Power BI Desktop project report folder

    Microsoft Learn ·

    https://learn.microsoft.com/en-us/power-bi/developer/projects/projects-report

  12. [12]
    Power BI MCP servers overview

    Microsoft Learn ·

    https://learn.microsoft.com/en-us/power-bi/developer/mcp/mcp-servers-overview

  13. [13]
    Power BI Authoring MCP server

    Microsoft Learn ·

    https://learn.microsoft.com/en-us/power-bi/developer/mcp/power-bi-authoring-mcp

  14. [14]
    Prepare your data for AI to improve Copilot results (preview)

    Microsoft Learn ·

    https://learn.microsoft.com/en-us/power-bi/create-reports/copilot-prepare-data-ai

  15. [15]
    Copilot in Power BI tutorial: Get started

    Microsoft Learn ·

    https://learn.microsoft.com/en-us/power-bi/create-reports/tutorial-copilot-power-bi-get-started

  16. [16]
    Fabric data agent concepts

    Microsoft Learn ·

    https://learn.microsoft.com/en-us/fabric/data-science/concept-data-agent

  17. [17]
    Microsoft Fabric adoption roadmap maturity levels

    Microsoft Learn ·

    https://learn.microsoft.com/en-us/power-bi/guidance/fabric-adoption-roadmap-maturity-levels

  18. [18]
    Power BI implementation planning: Adoption tracking

    Microsoft Learn ·

    https://learn.microsoft.com/en-us/power-bi/guidance/powerbi-implementation-planning-adoption-tracking

  19. [19]
    Monitor usage metrics in Power BI workspaces (preview)

    Microsoft Learn ·

    https://learn.microsoft.com/en-us/power-bi/collaborate-share/service-modern-usage-metrics

  20. [20]
    Previous monthly updates to Power BI Desktop and the Power BI service

    Microsoft Learn ·

    https://learn.microsoft.com/en-us/power-bi/fundamentals/desktop-latest-update-archive