Write the analytics questions before the Dataverse schema

Someone is waiting on a decision

Every dashboard request I have reviewed in the last few years arrived as a list of visuals. A bar chart by region, a trend line by month, a card with the total. What nobody wrote down was the decision the person asking would make once they saw it, and that gap is where most Power BI work on top of Dataverse goes wrong. The build goes fine. The page renders. Then the operations director asks the one question the model cannot hold, and the team is back in the backlog.

So the first thing I do with a request is take the visuals off the table and ask for the question in the leader's own words. Which decision is delayed today, and what evidence would change it? A regional manager who says she needs open work orders by technician usually means she has to decide whether to move two people between depots next week and does not want to guess. That sentence tells you the grain, the dimensions, and how fresh the data has to be. The bar chart never did.

Written down, the questions become a requirement the build can be checked against, alongside the form layout and the security roles. Building the page around the decision is the design half. This piece covers the part that comes before the design, when the tables are still being drawn.

The tables were drawn for the form

The usual project shape on Microsoft's stack is that the app team designs the Dataverse tables to make the model-driven form work, and the analytics team is invited in a fortnight before go-live to point Power BI at whatever exists. I sat in one of those reviews for a field service rollout. The work order table had a status choice column with eleven values, no timestamp for when a job actually finished, and region only on the account record three lookups away. The leadership question was which regions were missing their service window this month and whether the trend was getting worse. Not one part of that question could be answered from the model as built.

The fix was ordinary. A completed-on datetime set by the flow that closes the job. A region column stamped onto the work order at creation, so the report does not have to chase a lookup chain that changes whenever an account is reassigned. A status reason grouping that collapses eleven values into the four the director cares about. Each of those is a ten-minute change during design and a migration with backfill after go-live. Getting the questions in front of the data architect before the tables are locked is the whole point.

The same discipline applies to identifiers. If the question will be asked across the CRM and the ERP, the work order needs a key that both systems keep, and choosing that key deliberately beats reconciling on a customer name six months later.

Freshness is a requirement nobody writes down

The second thing that goes wrong is timing. A Dataverse-backed Power BI dataset on scheduled import refresh usually runs overnight. The Monday operations meeting is at nine. Someone opens the report, sees Friday's numbers, then opens the app on their phone and sees three jobs that closed that morning. From then on the conversation in the room is about which number is right rather than about the decision, and the report has lost the trust it needed to be useful.

Ask each question how old the answer is allowed to be. Some questions are fine at a day old, and an import model with a nightly refresh is cheaper to run and easier to shape. Others get asked in the middle of a shift, and those want DirectQuery against Dataverse, a Fabric link, or an honest label on the page that says when the data was taken. The answer changes the architecture, the licensing, and the size of the model, which is why it belongs in the requirement rather than in a support ticket a month after go-live.

Freshness also settles the argument about where the numbers should live. Operational questions that need this morning's records sit close to the application. Questions that need three years of history and a stable set of definitions belong in a governed layer, and keeping the flexible analysis apart from the controlled record is easier to design in than to retrofit.

Active means four different things in the same tenant

Once the questions are on paper, the same word turns out to carry different meanings for different teams. Active customer means bought something in twelve months to sales, has an open contract to finance, and has logged in this quarter to the product team. Completed means the technician pressed the button on one team and the invoice went out on another. A Power BI page that shows a single active customers card without saying which definition it uses will be quietly wrong for two of the three audiences, and they will find out in a meeting.

So every measure in the semantic model gets a definition and a steward beside it, in the measure description where a reader hovering in the report can see it and in the requirement document where the steward signed it off. The steward is a person with a job title, and the definition names the table and the filter and spells out the date logic in plain words. When two teams disagree on the word, the fix is two measures with two honest names rather than one measure with a footnote. Deciding who owns a contested definition is a governance call that the analytics team can raise but should not settle alone.

What the question record looks like

The artefact I ask for is one page, and it is deliberately boring. Each question gets a row, and the row carries enough that a data architect can shape a table from it and a report builder can shape a page from it without going back to the leader. When a project cannot fill in a row, that is the finding, and it is a cheaper finding on a whiteboard than in user acceptance testing.

• The question, in the words of the person who will ask it.
• Who asks it, and in which meeting or moment.
• The decision it feeds, and what they would do differently with a different answer.
• The grain, meaning one row per what, and the dimensions they will slice by.
• How old the answer may be before it stops being useful.
• Every measure named in the question, with its definition and its steward.
• Where the data is captured today, and the field that is missing if it is not.

The sentence to use in the design review

This only works if the list is in the room when the tables are designed, which means the analytics conversation has to happen in the first design review rather than the last. On most Dynamics 365 and Power Platform projects that is a scheduling change rather than a budget one. Invite whoever will build the Power BI model to the session where the Dataverse tables are drawn, and send them the question list the day before.

The sentence I use when a request lands as a list of charts is short. Tell me the question you will ask on the day this goes live, and tell me what you will do with the answer. If the requester cannot, the request is not ready, and no amount of modelling will make it ready. If they can, you already have most of the schema, the refresh design, and the measure definitions, and the analytics work becomes checking the build against the list instead of guessing what the leader meant.

So before the next design review, take the current backlog of dashboard requests and try to write one question row for each. Count how many rows you cannot finish. That number is the size of the requirement gap on your project, and it is the first thing to show the sponsor.