A direct model over Dataverse answers more than people admit
Most reporting requests that land on a Power Platform team can be answered by a report that reads Dataverse directly, and the team that responds by designing a data platform has usually spent six months solving a problem it did not have. A sales manager wants open opportunities by owner. Service wants the cases that breached response time this week. Finance wants last month's invoiced total by country. All three read current values out of tables that already hold them.
A model built straight over the operational tables has fewer moving parts than anything else you could put in its place. There is no pipeline to schedule, no staging layer to document, no second copy of a field that somebody renamed last Tuesday. When the business adds a value to a choice column, the report picks it up. When somebody asks why a number moved, the answer sits one click away in the record that produced it.
The honest version of the argument starts there. Copying business application data into an analytical store is a real investment with real running costs, and the burden of proof sits with the copy. Three things shift that burden, and none of them concern which product has the longer feature list.
History is the first reason a copy earns its keep
Operational systems overwrite. A case owner field holds the current owner, an opportunity stage holds the current stage, and an employee's cost centre holds the one they sit in today. That design is right for the people working the records, and it quietly destroys the thing analytics needs most, which is knowing what a value used to be.
Ask a sales director how the pipeline looked at the end of last quarter and a direct model will tell you how it looks now, filtered to records that existed then. Those are two different answers. Stage movement, ownership changes, forecast churn and reopened cases all live in the gap between them. Dataverse retains some change information, and how much of it you can practically query depends on what your organisation has turned on and how long it keeps, so confirm that for your own tenant before you promise anyone a trend line.
Once a business genuinely needs point-in-time answers, you are building snapshots, and snapshots want somewhere to live outside the operational database. That is where the heavier option starts paying for itself. The test is whether anyone will make a different decision because they can see last quarter's shape, or whether they only said so in a workshop.
Volume, query shape and the join nobody planned for
The second reason is the workload. A report that reads one customer's open cases and a report that scans four years of transaction lines are different jobs. The first is a handful of rows over an index. The second pulls millions of rows across a service built to write one record at a time reliably, rather than to sweep an entire table on demand.
You feel this long before you hit any hard limit. Refreshes creep from four minutes to forty. Somebody adds a slicer and the page takes twelve seconds. A throttling limit gets hit mid-morning and a business user reports that the operational app has gone slow, which it has, because the report is competing with it for the same capacity. No amount of tuning inside a Power BI model fixes a workload that belongs somewhere else.
Joining across systems is the reason most organisations genuinely end up with a shared analytical layer, and it is the most defensible reason of the three. Cost to serve needs cases from Dynamics 365 and hours from the finance system. Churn analysis needs contract dates from one place and support history from another. Neither system can answer alone, and wiring them together inside a report file puts the join logic somewhere one person owns and nobody reviews, which is the same pressure described in where a lake meets a ledger.
A second copy is a second answer to the same question
Every copied dataset creates a second source of truth with its own clock. The operational screen shows a case closed at 09:40. The report shows it open, because the last refresh ran at 06:00. Both are correct, and somebody still has to sit in a meeting and say which one the business should act on.
Teams underestimate how expensive that conversation is. It recurs every month end, and each round of reconciliation costs hours from the people who can least afford to give them. Decide the refresh tolerance up front and publish it next to the numbers, so a finance analyst reading the figure knows it reflects last night rather than this morning, and stops treating the difference as a defect.
The commercial side depends on your agreement. What an analytical copy costs in capacity, storage and licence terms varies by tenant and by region, and those terms move, so get a written answer from whoever holds your contract before anyone signs off a design that assumes the cheap version.
Row-level security does not travel with the data
The harder cost is security. Operational access in Dataverse comes from business units, teams, roles and record ownership, and the platform evaluates those rules every time somebody opens a record. Copy the rows into an analytical store and none of that comes with them. The store sees a table.
Recreating the rules is real engineering work, and it is easy to get subtly wrong in a way no test catches. A role mapping that misses the users who moved teams in the last reorg. A manager hierarchy rebuilt from a field nobody has maintained since 2023. Getting a report wrong means somebody complains. Getting this wrong means a regional director reads salaries or one partner sees another partner's pipeline, and nobody complains at all, because the people who should not see it are perfectly happy.
Give the security model of the analytical copy its own design, its own test cases and its own sign-off from whoever owns the data in the source system. If the project plan has a line for pipelines and no line for that work, the plan is wrong. The same habit that keeps Dataverse capacity from surprising you applies to access, and retrofitting it after an audit finding costs far more.
The questions to ask before you approve the build
Four questions settle most of these arguments. Does anyone need to know what a value was on a date in the past, and will a decision actually change because of it. Does the question cross a system boundary that no single application owns. How stale can the answer be before the business stops trusting it. Who runs the result in eighteen months, once the consultant has gone and the person who built it has changed jobs.
That last question decides more projects than the first three. An analytical platform needs people who patch it, watch refreshes, answer for a number at quarter end and say no to the fourteenth request for a bespoke extract. The business applications team is usually not that team, and volunteering them in a steering meeting is how you end up with pipelines nobody has opened since go-live. With no owner who has capacity, the lighter option wins.
Both answers are legitimate. Plenty of organisations run serious analytics practices for sound reasons, and plenty serve hundreds of users well from direct models. The expensive mistake only runs one way, which is building the heavy option for a need the light one already served, then paying every month in failed refreshes, reconciliation meetings and a security model nobody fully understands.
Take the request sitting on your desk this week and ask the person who raised it to state the exact question with a date attached. If the question is about today and lives inside one system, build the report and move on. If they cannot phrase it without saying what it looked like in March, or without a number that lives in another application, you have found the requirement that justifies a platform, and you should write it down in those words before anyone starts costing licences.
