A Fabric App demo can be built fast, especially with AI assistance. A working page that reads a semantic model, renders like a polished web app and does something a report cannot, that can exist in days. The speed is real and it is genuinely useful for discovery.

It is also the trap. Because the thing that makes a demo fast to build is precisely the set of questions it lets you skip: who owns this, who reviews changes to it, what happens when the model underneath it shifts, who gets the call when a user says a number looks wrong. A Power BI report answers most of those questions by convention, because the platform and your organisation already have a shape for it. A Fabric App is a custom web application on top of your data, and it answers none of them by default. You do.

We built a finance Fabric App demo (a dashboard plus forecast writeback) and, because we build these for clients, we were deliberate about the line between “demo-grade” and “production-grade” from the start. This post is about that line: the governance and maintainability work a Fabric App needs before it is more than a demo, drawn from the actual guardrails we put around ours and the specific reasons a demo is not production even when it looks finished.

The short version: the demo is the easy 90% of the effort and the last 10% is most of the risk. Everything below is that last 10%.

The visible part is not the quality signal

The first thing anyone notices about a Fabric App is the interface: custom visuals, app-style navigation, a guided experience instead of a report canvas full of slicers. That is the part that gets attention in a demo, and it is the part that matters least to whether the app can be trusted.

The quality signal sits underneath, and it is mostly invisible in a demo: can the semantic model reliably answer the questions the app asks, are the queries against it validated, is there a clear owner for the app code and a separate clear owner for the model, and is there a defined path for a change to reach users without breaking them. A demo can score perfectly on look and zero on every one of those, and from the outside the two are indistinguishable. That gap between what a demo shows and what production needs is the whole subject here.

At the time of writing this, July 2026, Fabric Apps are still in preview.

The Fabric App landing page. The interface is the visible layer. Whether the app is production-grade is decided by things this screenshot cannot show.

Ownership is two questions, not one

The instinct is to ask “who owns the app?” In a Fabric App there are two owners and they are usually not the same person, which is exactly the complication a report does not have.

There is the app code: the React, the TypeScript, the queries, the layout, the deployment. And there is the semantic model: the tables, the relationships, the DAX measures, the security rules. In our build these are cleanly separate concerns, and the separation is not incidental, it is structural. The model’s fact and dimension tables are read-only to the app. The app reads them through the data service and cannot write to them. Anything the app needs to persist (in our case a forecast adjustment) goes to a separate writeable store, never into the model’s tables.

That read-only boundary is the single most clarifying fact for ownership. It means the model team can own the model and the app team can own the app without stepping on each other, because the app physically cannot alter the model’s data. But it also means a change on either side of the boundary can break the other, and nobody owns the boundary itself unless you deliberately assign it. The question production forces that a demo lets you dodge is: when a measure definition changes in the model, who is responsible for checking that the app still reads it correctly? In a demo, the answer is “the same person built both, so nobody had to ask.” In production, that person has moved on and the question is live.

Deployment is where a demo quietly becomes production

The most dangerous moment in a Fabric App’s life is the one nobody notices: the deploy where a prototype starts being used for real. Nothing technical marks it. The app that was a demo yesterday is load-bearing today, and if you have not built the discipline in advance, you build it after something has already gone wrong.

We put the controls in before the app was worth protecting, which is the only time it is cheap to do. Concretely, deployment runs through a single choke point: exactly one script is permitted to deploy, and it refuses to run unless several preconditions hold. It checks it is on the working branch and not the protected one. It checks the git tree is clean. It checks the deploy target is the one specific workspace and item it is allowed to touch, and refuses any other target outright. It logs every deploy. No deploy can happen any other way, and that is enforced, not merely requested.

The reason for a single guarded path is that ad hoc deploys are how demos rot into production without anyone deciding they should. If any developer can push the live app from their machine on a whim, there is no moment where a change is reviewed, and “it worked on my screen” becomes the release process. Funnelling every deploy through one gate creates the checkpoint that a report gets for free from its publishing model.

Alongside that, the main branch is protected: changes reach it only through review, never by a direct push, and several categories of action are blocked outright by automated guards rather than left to good intentions. Destructive operations against the data, edits to secret and credential files, and any write while on the protected branch are all refused at the tooling level. The principle we followed throughout: a rule that depends on everyone remembering it is not a control, it is a hope. If it matters, it should be impossible to violate by accident, not merely discouraged.

One guarded deployment path, a protected main branch, review before release. The controls a report inherits by convention, an app has to be given.

Secrets and auth: the boundary a script cannot cross

Here is a concrete production consideration that a demo surfaces in an awkward way, and it is worth stating plainly because it caught us out before we understood it.

The credentials the app needs to reach its data live in environment and configuration files that must never enter version control and must never be edited by an automated process. We enforced that with a hard guard: the build tooling is blocked from touching those files at all, with no exception path. Any change to them is a deliberate human edit in a separate session, and the files themselves are kept out of the repository and backed up separately. That is ordinary secure practice, but a Fabric App makes it your responsibility explicitly, where a report keeps it inside the platform.

The sharper, less obvious one: the app’s writes to its data store run under Fabric’s embedded authentication, which is tied to the signed-in user session inside the running app. A command-line or automated process cannot complete that authentication. It is not awkward, it is structurally impossible. For us that meant certain operations, seeding data, verifying what was written, can only happen as actions a signed-in human takes inside the deployed app, never as a script.

This matters for production planning far beyond the demo, because it dictates what can and cannot be automated in the app’s operations. If your maintenance plan assumes you can script the app’s data setup or run automated checks that write to its store, embedded auth says otherwise, and you need to know that at design time, not when you are trying to build a nightly job that cannot authenticate. Classify the operations that are structurally human-in-the-app from the start.

The demo will lie to you about maintainability in one specific way

A demo runs on a machine where the person who built it is present, the model has not changed since, and every dependency is exactly as it was. Production is defined by the absence of all three. The maintainability questions are the ones the demo conditions hide:

What happens when the model schema changes? A renamed column or a redefined measure that the app reads will not announce itself, the app will keep rendering, possibly with wrong numbers, exactly the way our own headline figure once read plausibly while being wrong. In production you need a way to catch that a model change has desynchronised the app, which means tests over the app’s important data journeys that run against the real deployed app, not just the developer’s confidence.

What happens when a user reports a number that looks wrong? In a demo, the builder investigates. In production, someone has to be able to trace a displayed number back through the query, to the measure, to the model, and that someone needs to exist and know the path. If ownership is unclear (the two-owner problem above), this is where it bites.

What is the rollback plan? A demo has none because it does not need one. A production app needs a defined way back to the last good state when a deploy goes wrong, and for an app that writes data, that plan has to account for the data written since, not just the code.

None of these are exotic. They are the standard concerns of running software, and that is the point: a Fabric App is software, and the demo is the one phase where you are allowed to pretend it is not.

Match the governance to the risk, and sometimes that means not building an app

The weight of everything above should scale with what the app is for. A throwaway internal demo needs almost none of it. An app that finance or operations leaders rely on needs most of it, and that starts to look like software delivery: version control, clear ownership on both sides of the model boundary, validated queries, tested user journeys, reviewed permissions, a rollback plan.

Which leads to the honest conclusion, the same one we reach on every one of these builds. Not every report should become a Fabric App. If the deliverable is something people read and explore, a Power BI report is faster to build, cheaper to maintain, and comes with an ownership and governance model your organisation already understands. The app earns its governance cost only when it does something a report fundamentally cannot, and even then the cost is real and should be counted before you start, not discovered after the demo has quietly become the thing everyone depends on.

We built the controls into our demo not because a demo needs them, but because the distance between a demo that has them and one that does not is exactly the distance between something you can put in front of a client and something you can hand to a client. That distance is the work. It is mostly invisible, it is almost all in the last stretch, and it is the part worth asking about before anyone is impressed by the interface.

To learn more about Microsoft Fabric and how we can help with Fabric Apps, see our Microsoft Fabric page.

The post Lessons from a Fabric App demo build appeared first on Data Bear.

We set out to build a finance commentary writeback report in Power BI using Fabric translytical task flows. The interaction sounds trivial: select a finance row, type an explanation, click a button, write the comment to a Fabric SQL Database, and show it back against the same row. The Python that does the insert is a dozen lines. It was the easy part, and it was working early.

Everything that actually took the time lived in the seams between the pieces: deciding what a single comment is really attached to, keeping the finance facts immutable, getting one selected key out of a Power BI table, fixing service-side authentication that looked like a wrong server name, mapping button parameters that a published-and-tested function still would not accept, and telling a correctly-filtered empty visual apart from a broken one. Two of the most alarming “the data is gone” moments turned out not to be data failures at all.

This is the build diary we would have wanted before we started: the route that worked, the false leads, the specific platform behaviours, and the point where a translytical task flow stops being the right tool and you should reach for an application instead.

One clarification up front, because we have written separately about building forecast writeback inside a full Fabric App. This is a different pattern. Here the writeback lives inside an ordinary Power BI report, driven by a data-function button against Fabric User Data Functions. It is the lighter-weight option, and a large part of what we learned is exactly where its natural ceiling sits relative to a full app. More on that at the end.

Two apparent data failures that were really report-state failures

The most useful lesson of the build came from two bugs that both looked like the data had vanished and were both nothing of the kind. We are putting them first because they are the heart of what makes translytical reports different from ordinary ones.

The report has a one-to-many relationship from the finance view to the commentary table:

vw_FinanceDemo[FinanceKey] 1 → many FinanceCommentary[FinanceKey]

The first bug appeared the moment we added a comment count to the finance table:

Comment Count = COUNTROWS(FinanceCommentary)

Almost every finance row disappeared, leaving only the single row that had our one manually inserted test comment. It looked exactly as though the relationship had filtered the finance data down to nothing. It had not. The measure returned blank for every row with no commentary, and the visual dropped the blank rows. Converting blank to zero brought them all back:

Comment Count = COALESCE(COUNTROWS(FinanceCommentary), 0)

The second bug was subtler and more instructive. The commentary history visual showed a comment even when no finance row was selected, because nothing was restricting it. We added a Show Selected Commentary measure as a visual-level filter and set the finance table’s interaction to Filter, so commentary appears only when exactly one row is selected. That fixed the behaviour but created an ambiguity that matters:

A blank commentary table can mean two completely different things. Either the visual is not receiving the selected-row context (broken), or the visual is correctly filtered and that row simply has no comments yet (working). We hit this exact ambiguity during final testing: the selected-row card was populated, the commentary table was blank, and for a moment it looked like a filter failure. It was the opposite, a correctly selected row with no commentary. The blank was the right answer.

Single finance row selected, selected-row card populated, commentary history correctly blank because no comments exist yet

That is the whole character of this kind of report in one example. A translytical report is a stateful interface, and the model has to account for every state: no selection, one selection, several selections, blank input, a successful write, a failed write, and a successful write that is not yet visible. In a production version we would make the empty state explicit (“No commentary recorded for this finance row”) so that zero records can never be mistaken for a broken interaction.

What the comment is attached to is the real design question

Microsoft’s standard tutorial uses the small AdventureWorksLT sample and writes back a product description. That is fine for showing the mechanics, but it hides the decision that actually matters in finance, because in a product-description example the target row is obvious. In a finance report the visible row might be a fact row, an aggregate, a subtotal, or a measure evaluated under several filters. Before you can write a comment, you have to define precisely what it is a comment on.

So we used the larger AdventureWorksDW2022, whose FactFinance gives real amounts by date, account, scenario, organisation and department, and we made the central modelling decision early: FactFinance stays immutable. A finance amount and a user’s explanation are different kinds of record. The amount is analytical data; the explanation is an auditable action with its own author, timestamp and lifecycle. They belong in different tables, so commentary went into a separate dbo.FinanceCommentary and the fact table was never touched.

Our first commentary design stored all the dimensional keys explicitly, date, account, organisation, department, scenario. It was descriptive but it made the button contract far too wide: a single click would have had to pass several key values reliably, with a real chance of a partial or inconsistent combination. So we collapsed the contract to a single surrogate FinanceKey. Power BI passes one integer; the function resolves everything else from that row.

The key stays hidden from the user. The report shows a friendly Selected Finance Row card with recognisable business context, while the FinanceKey exists only to carry the function call.

[Screenshot: selected finance row card showing business context while FinanceKey stays hidden]

This works because the demo comments against one physical finance row. It would be the wrong key for a comment like “total operating expenses for Q3 across all organisations.” An aggregate comment needs a stable aggregate grain, account plus fiscal period plus organisation scope, or a dedicated review entity. Reusing an arbitrary underlying fact key would make an aggregate comment look precise while quietly attaching it to the wrong business object. That boundary is the single most important thing to get right before extending this pattern.

The function was short; proving its boundary was the work

The user data function, addFinanceCommentary, takes the three values the report can supply reliably:

addFinanceCommentary(
    financeKey: int,
    commentText: str,
    createdBy: str
) -> str

The -> str return type is not incidental: Power BI data-function buttons require a string-returning function. In production that string should be a designed, user-facing result, not a raw exception dump.

We tested the function in isolation in the Fabric portal before wiring it to anything, passing a known key, a test comment and a test user. It returned Commentary saved. and a SQL query confirmed the row. That single isolation step paid for itself repeatedly later: once the insert was proven independently of Power BI, every subsequent failure could be attributed to selection, mapping, publication, permissions or refresh, never to the SQL.

Fabric User Data Function portal test returning “Commentary saved.”

Two small platform snags cost real time here. The connection alias rejected an underscore: finance_sql was refused and FinanceSql accepted, the field only takes alphanumerics in this experience. And the Fabric interface caused a genuine terminology hunt, we were looking for a way into “Develop mode” when the item was already in Develop, shown by the mode selector at the top right. Neither is conceptually hard; both are exactly the kind of undocumented friction a diary like this exists to warn you about.

Selecting the function did not configure the button

This was the most misleading interface state in the whole build. We chose the Data-function action, connected the published function, and the selection completed cleanly, yet hovering the button warned:

The data function is not properly configured.

Because the function was already published and had passed its portal test, this looked like the connection had failed. It had not. Selecting a function and supplying its inputs are two separate steps, and nothing on screen made that obvious. We added and mapped the three parameters by hand:

financeKey  → Selected FinanceKey
commentText → input slicer value
createdBy   → Writeback User

Selected FinanceKey uses SELECTEDVALUE, deliberately returning blank unless exactly one row is in context. The input slicer supplies the free text. Writeback User uses the signed-in Power BI identity. The moment all three mappings existed, the warning cleared.

Power BI button action settings with financeKey, commentText and createdBy mapped]

We then saved, republished over the existing report and semantic model, opened the report in the service, selected one finance row, typed a comment, and clicked the button. It completed, the row was written, and after the visuals refreshed the new comment appeared against the same selected FinanceKey. The full loop, report selection to database insert to refreshed DirectQuery visual, worked end to end.

The new comment appearing in the commentary history after clicking the writeback button

DirectQuery was a choice, and it exposed an authentication trap

We chose DirectQuery deliberately, not by default. The point of the demo is a visible writeback loop: the user clicks and expects the comment to appear. An Import model would insert the row but not surface it until a semantic-model refresh, which breaks that expectation. DirectQuery shows the new row immediately. The trade-off is that it pushes performance pressure to query time, our simple view was fine for a sample but should not be assumed to scale to a large finance model without query, indexing, concurrency and capacity testing.

One earlier snag on the way in: we started in Power Query Online and could not find a DirectQuery option. The source was fine; the surface was wrong. The model and report interaction have to be built in Power BI Desktop, using the SQL Server connector against the Fabric SQL server and database, with DirectQuery selected there.

Publishing then exposed the trap worth remembering. Desktop connected perfectly, but the semantic-model credentials in the service were set to Basic authentication, and the resulting error complained about being unable to open server databear.com, which made it look like a wrong server name rather than an auth-mode problem. Switching the service-side credentials to Organisational/OAuth resolved it immediately.

Semantic model data source settings after changing authentication from Basic to Organisational/OAuth

The lesson generalises: a successful Desktop connection only proves the Desktop connection. It says nothing about whether the published semantic model, the Fabric SQL Database, the user data function and the report viewer are all using the intended identity. We would not call this production-ready until it had been tested with a non-owner account and the Execute, data and row-level permissions verified independently.

Getting the finance database into Fabric took a local detour

The demo data path was more involved than the tutorials suggest, because we wanted the richer warehouse sample rather than the lightweight one. The route that worked:

AdventureWorksDW2022.bak → local SQL Server restore → .bacpac export → Fabric SQL import

The machine had neither a local SQL Server nor SSMS to begin with, so those went on first. During the restore we lost track of whether “relocate all files” had been ticked; rather than restart, we just asked the database:

SELECT name, state_desc FROM sys.databases WHERE name = 'AdventureWorksDW2022';

It returned ONLINE, which settled it without redoing the step. SqlPackage was the next gap, and its first install route wanted a whole .NET SDK we did not otherwise need, so we used the standalone Windows package instead and exported a roughly 16 MB .bacpac, then imported it into an empty Fabric SQL Database with Entra interactive auth and confirmed the finance fact and dimension tables were present before building anything on top.

Fabric SQL Database explorer showing FactFinance and the finance dimensions after import

This is fine for standing up a demonstration database. It is explicitly not a deployment lifecycle. For anything ongoing, the schema, views, writeback tables and permissions belong in scripts under source control; a .bacpac moves a starting dataset, it is not database change management.

Debugging by proven contracts

The reason the build stayed manageable is that we proved each layer before the next depended on it, which turned a vague “why doesn’t writeback work” into a precise “which contract is proven, and which is the next unproven one.” The chain was:

backup → local database
local database → bacpac
bacpac → Fabric SQL
finance tables → reporting view
report selection → one FinanceKey
Power BI inputs → function parameters
function → SQL insert
SQL insert → refreshed DirectQuery visual

That framing is what stopped us fixing the wrong thing. When the function worked in the portal but the button warned about configuration, there was no reason to touch the SQL. When finance rows vanished after adding the count measure, there was no reason to reimport the warehouse. When the commentary table was blank for a row with no comments, there was no reason to change the relationship. Each failure could be isolated to one contract because every earlier contract was already proven.

When this pattern is the right choice

This architecture is at its best when the user is already making a bounded decision inside Power BI and the action ties cleanly to a stable reporting object. Commentary fits perfectly: the input is small, the volume is low, the user’s context is already on screen, and the write can be stored separately with a timestamp and identity. The same shape supports a variance-review status, an owner assignment, an approval flag, an exception note, or a controlled planning adjustment held outside the system-of-record facts.

The real test is not whether Power BI can call a function. It is whether the action has a clear grain and a small, auditable contract. In our build that contract was one FinanceKey, one comment, one identity. It also demands a report designer willing to treat report state as application state: selection cardinality, blank inputs, error feedback, refresh latency and permissions are not edge cases here, they are the user experience.

When it is the wrong choice

We would not use this to edit accounting actuals, post journals, or change governed ledger facts. Appending commentary or workflow metadata to a separate table is safe; mutating system-of-record transactions is a different control problem entirely.

We would also avoid it for high-volume or spreadsheet-style multi-row entry, offline work, attachment-heavy processes, long-running approvals, complex cross-field validation, or records several users edit at once. Those needs point to a Power App, a model-driven app, or a full Fabric App, with Power BI kept as the analytical surface. This is exactly the line between this pattern and the Fabric App forecast-writeback build we have written about separately: when the interaction outgrows a single bounded action, you have left translytical territory.

There are also current service limits worth knowing before you plan a team around this. During our build, only the item owner could edit and publish the function, and service-principal access to Fabric items and data sources was not supported. Those constraints shape ownership, deployment and identity design even when the report itself works fine.

What we would change before production

The demo works end to end, but “works in a demo” and “ready for users” are different bars. We would guard the button so it is disabled when no single row is selected or the input is empty, and make the empty commentary state an explicit message rather than a blank table. We would move the schema and function code into source control with a repeatable deployment, separate commentary permissions from finance-read permissions, and have the function enforce authorisation itself rather than trusting the report interface, then test the whole thing with a non-owner account and verify row-level security, SQL permissions and function Execute permissions independently.

We would also settle the commentary lifecycle, which is currently append-only. A production owner has to decide whether comments can be edited, whether edits create versions, whether a comment can be superseded, and how deletions show up in the audit history. And we would test query performance and concurrency at realistic volumes, since DirectQuery’s responsiveness comes at the cost of depending on source-query performance at interaction time.

The practical conclusion

The working part of this writeback demo was never the Python. It was a chain of explicit contracts across SQL, Fabric User Data Functions and Power BI, and the decisive choices were all modelling and interaction ones: keep commentary out of FactFinance, reduce the report-to-function contract to a single FinanceKey, expose context through a friendly card while hiding the key, choose DirectQuery so the write is visible, and treat report state as application state.

The most misleading failures were never backend failures. A blank count hid the finance rows. A correctly filtered empty table looked broken. A published, tested function still threw a configuration warning until its parameters were mapped. A perfect Desktop connection masked a wrong service identity. Each one tempted us to fix a layer that was already sound.

That is the decision frame we would give any finance team considering this. When the action is narrow, contextual, low-volume and auditable, a translytical task flow removes the friction of leaving Power BI and hunting down the same business context somewhere else. When the workflow starts to need a real application’s data-entry, concurrency, approval and lifecycle capabilities, build the application. Knowing which side of that line you are on, before you start, is most of the job.

Learn more about how we can help you with your Power BI writeback requirements.

The post Power BI finance writeback translytical task flow appeared first on Data Bear.

Most write-ups about Microsoft Fabric Apps stop at the same place: here is a data app, here is a chart, look how it resembles a web application instead of a report. That is the easy 80%. The interesting question is what happens when you ask a Fabric App to do the one thing a Power BI report structurally cannot: let a user change a number and have that change survive as governed, audited data.

We built exactly that. Our Finance Writeback demo is a Fabric App that reproduces a Power BI financial dashboard and then adds forecast writeback on top: a finance user opens the Plan page, increases a marketing forecast by £60,000, watches the affected totals recalculate on screen, then saves it as a draft, submits it for review, and commits it. Every one of those actions lands in an append-only audit log. No semantic model refresh, no export to Excel, no email thread. The number changes in the report because the user changed it in the app.

This post is the build log for the parts that actually bit us, because those are the parts you cannot get from the documentation.

Why writeback is the real test, not “does it look like an app”

A store or finance manager rarely needs a prettier dashboard. They need to answer a question and then act on it. The reporting half of  the Fabric Apps demo (the Financial Overview) is genuinely just table stakes: Power BI already renders an income statement with actuals, budget, prior year and variance perfectly well, and if that is all you need, a report is cheaper to build and easier to maintain. We say that plainly in our own scope: pixel-replicating read-only report pages is disproportionately expensive relative to the demo value.

The differentiator is the write path. When a forecast adjustment can be entered, recalculated, saved, submitted, committed and audited inside the same surface the user is already looking at, the app stops being a report and becomes a small piece of finance software. That is the boundary where a Fabric App earns its place, and it is the boundary this post lives on.

The sign convention that makes a correct demo look broken

Here is the first thing nobody warns you about, and it cost us a genuine bug twice before we pinned it.

In the finance dataset, expenses are stored as negative values. October’s Digital Marketing budget for the UK entity is not `80,892`, it is `-80,892`. That is correct and normal at the data layer. The problem is what “increase spend by 60,000” means once you are in negative space: increasing spend makes the stored number *more* negative. `-80,892` becomes `-140,892`, and the delta the audit log records is `-60,000`.

If you render those raw signed values to a finance user, the demo looks broken. They asked to spend more and the number went down. So the app has to store signed and display friendly: the screen shows “Forecast 140,892” and “Spend +60,000” while the database holds `-140,892` and `-60,000`. Get this backwards in even one place and either the maths is wrong or the screen is confusing, and the two failure modes look identical from the outside.

The fix that actually held was to stop treating sign as a formatting afterthought. We centralised the whole convention, the magnitude flip, the stored-from-display conversion, the delta maths and the formatters, into a single module and reused it everywhere. The lesson generalises well beyond finance: when a domain has a storage convention that inverts the user’s mental model, that conversion is not display polish, it is a load-bearing part of the data contract, and it belongs in exactly one place.

A related trap on the same theme: there were two amount columns in the model, a raw local-currency `Amount` and a converted `AmountUSD`. Computing on the wrong one was the single root cause of our original KPI miss, and it tried to come back a second time when we built the writeback recalculation. If you take one portable thing from this post, let it be: find out which column is authoritative before you write a single measure, and write it down where the next person will see it.

The edit updates the affected line and its full-year total on screen, before anything is saved.

The constraint that quietly reshapes the whole architecture: embedded auth

This is the one we most wish someone had told us at the start, and it is now the first thing we classify on any new Fabric App.

The writeback runs against Rayfin SQL under Fabric’s embedded authentication. That auth is tied to the signed-in session inside the deployed, running app. A command-line or headless process cannot complete it. Not “it is awkward from the CLI”, it genuinely cannot obtain the credential.

That single fact reshapes everything downstream. It means you cannot seed your working forecast from a script. You cannot verify the persisted rows from a terminal. You cannot drive the writes from any automated Node process at all. Every operation that touches the writeback tables, seeding the baseline, saving a draft, reading back what was stored, has to happen as a click inside the app, by a signed-in human.

We spent real time discovering this the hard way before we understood it was structural rather than a bug in our setup. The takeaway we now carry: identify the operations that are structurally un-automatable, embedded-auth writes, in-app-only steps, at intake, and plan them as expected human-in-the-app steps from day one. If you assume you can script your test data and you cannot, you find out at the worst possible moment, mid-build, with a demo date approaching.

Writes and reads are not symmetric, and treating them the same is a bug

Once you accept the app is doing real writes, retry policy stops being boilerplate.

Reads are safe to retry. If a read fails on a transient cold-mount error, firing it again just gets you the same rows. We gave reads a single one-shot retry for exactly that transient 5xx case, plus a manual retry button, and moved on.

Writes are a different animal. A forecast “save” that silently retries can create the row twice. There is no safe transparent retry for a create, because you cannot tell from the outside whether the first attempt failed before or after it wrote. So writes get *no* transparent retry. When a write fails, the app surfaces an explicit Retry control and hands the decision to the user, who can check whether the row is already there.

This is a small design decision that only shows up once you are writing rather than reading, and it is invisible in any demo that never persists anything. It is also the kind of thing a generic “how to build a data app” article will never mention, because that article never had to worry about a duplicate committed forecast.

The state machine, and why “committed” is the only status that counts

The lifecycle is Draft to Submitted to Committed, and each transition does specific work:

A **Draft** is editable by its owner and is deliberately *excluded* from the adjusted forecast total. **Submitted** locks the row to its owner and marks it pending review. **Committed** locks it permanently and is the only status whose delta actually merges into the adjusted forecast. Draft, Submitted and Rejected are all filtered out of the total. This matters because it means a half-finished “what if” a user is still typing never contaminates the headline number. Only a deliberate commit moves the forecast.

Every transition appends exactly one audit row: old value, new value, signed delta, timestamp, user email. And the original baseline is never overwritten. The adjusted forecast is always baseline plus committed deltas, computed, never a destructive edit to the source figures.

Submit and commit are one-way locks, and only a commit moves the forecast total.

The append-only audit trap: a clean demo is a data-layer job, not a UI feature

Here is the lesson that surprised us most, and it is a genuinely portable one.

The audit page is append-only by design. No delete control in the UI, no “undo”, no casual reset button, because a finance audit trail that a user can quietly edit is not an audit trail. That is obviously the right call for governance.

But it collides head-on with a demo requirement: you need to rehearse the full Draft-to-Save-to-Submit-to-Commit story repeatedly, from a clean slate, in front of different audiences. And you have just deliberately built a system with no way to get back to a clean slate from inside the app.

The naive instinct is to add a reset feature. That instinct is wrong, and recognising why is the lesson. If you add an in-app reset, you have compromised the append-only guarantee you just spent effort building; the feature that makes the demo convenient is the exact feature that makes the audit trail untrustworthy. The correct answer is that a repeatable-clean-state requirement, when combined with an append-only data model, forces an out-of-band reset at the data layer. Not a UI feature. In our case that is a direct, scoped, preview-gated SQL delete against the Fabric endpoint, run deliberately by a human between rehearsals, never something the app itself can do.

The generalisable version: when you design any append-only or no-delete model, ask at that moment how clean state will be re-established, and commit to answering it at the data layer. If you defer that question, you will eventually be tempted to answer it with a UI feature that quietly undermines the whole point.

Clean state for the next demo happens at the data layer, out of band, by a human.

When you should not build this at all

A Fabric App is not automatically the right answer because it is newer. If your users need flexible, exploratory analysis and never need to write anything back, a Power BI report is cheaper to build, easier to maintain, and better suited to weekly visual iteration. If your team has no appetite to own custom code, an app is a liability, not an asset. The writeback demo earns its place precisely because writeback is something the report genuinely cannot do. If your requirement does not include that write path, use the report.

What this actually proves

The reporting layer of a Fabric App is the part everyone shows you and the part that matters least, because Power BI already does it. The writeback layer, edit, recalculate, save, submit, commit, audit, with the baseline never overwritten and only committed changes moving the number, is where a Fabric App becomes something a report is not.

And the work that makes it trustworthy is almost entirely underneath the surface: getting the sign convention right so a correct demo does not look broken, planning around embedded auth that no script can cross, treating writes and reads as the different risks they are, and resolving the append-only-versus-clean-state tension at the data layer instead of papering over it with a button. That is the part worth writing down, because it is the part you cannot look up.

To learn more about Microsoft Fabric and how we can help with Fabric Apps, see our Microsoft Fabric page.

The post Fabric Apps – Finance Forecast Writeback appeared first on Data Bear.

Microsoft Fabric Apps let you build a data-driven application on top of the same semantic model that feeds your Power BI reports. One of the first things people want to try is the obvious one: take a report they already have in Power BI and rebuild it as a Fabric App page. We did exactly that, reproducing a financial overview dashboard, and this guide is the honest account of what that takes.

The short version up front, because it is the most useful thing we can tell you: in a Fabric App you are hand-building, in code, every visual that Power BI gives you out of the box. A sparkline, a formatted number, a chart with its months in the right order, these are configuration clicks in Power BI and lines of code in a Fabric App. That difference is the whole story, and everything below is a worked example of it. If your goal is simply a report, Power BI is faster. A Fabric App earns its keep when you need to do something a report cannot, and the reporting layer is the price of admission to that.

This is the Fabric App. Below is the Power BI version

To a viewer they are the same page. The effort is entirely in how each got built

What you are actually signing up for

Before the setup checklist, it helps to be clear about the mental shift. Power BI is a report authoring tool: you bind fields to a visual and the tool handles rendering, sorting, formatting, number abbreviation, tooltips and responsive resizing for you. A Fabric App is a web application: you have a blank canvas and a component library, and anything the page shows, you build.

Concretely, our stack split the work like this:

• React handles everything structural: the page layout, the left-hand navigation, the KPI cards, the tables, the toggles and selectors.
• TypeScript handles the data loading and the finance calculations.
• Vega-Lite handles the charts, and only the charts, the trend lines, the bar chart, the donut. That division matters: Vega-Lite is excellent for plotting a series but is the wrong tool for laying out a card or a grid, and trying to make it do layout is a common early mistake. Charts in Vega-Lite, everything else in React and CSS.

The data comes from the semantic model, the same one behind the Power BI report, read through the Fabric data service. You do not get Power BI’s visual layer along with that data. You get the numbers, and the job is to present them.

Below is Fabric Apps charts

Below is the Power BI version

Setup and prerequisites

Fabric Apps are a preview capability, so the setup has real prerequisites that will stop you dead if any one is missing. In our experience these are the ones worth confirming before you write a line of code:

A Fabric workspace where you have contributor or admin rights. The Fabric Apps workload enabled at the tenant level, which is an admin action, not something you can self-serve. A semantic model hosted on Fabric or Power BI capacity, with Build and Read permissions granted to you on that model. And the tooling to create and deploy the app itself, in our case the Rayfin SDK and its command-line workflow.

None of these are difficult individually, but they cross permission and tenant-admin boundaries, so if you are not the tenant admin, line those approvals up first. Discovering mid-build that the workload was never enabled is a frustrating way to lose a day.

One practical note that shaped our whole workflow: the app running locally on your machine has the layout but no live data. The only surface that renders the true figures from the model is the deployed app. So your loop is edit, deploy, look, not edit, refresh, look. Deploys cost real minutes, which quietly changes how you work, you batch changes and check them together rather than tweaking one pixel at a time.

The rendering fights, and how we won them

This is the part you came for. Every item below is something Power BI does silently and a Fabric App makes you build. None of them is conceptually hard. All of them cost time, and a few cost more time than they had any right to.

Sparklines in the KPI cards

Power BI puts a little trend line inside a KPI card with a checkbox. In a Fabric App there is no such checkbox. A KPI-card sparkline is a chart you build yourself: take the monthly series, draw it as a thin line in a small fixed drawing area, and place it beside the big number.

The subtlety is that a sparkline is not a shrunk-down chart. It has no axes, no gridlines, no labels, no markers, just the bare line. We built ours as a simple polyline in a hand-sized drawing area sitting next to the value, and the discipline was resisting the urge to add the things a normal chart has. Our first attempts crept in an end-of-line marker and a shaded fill under the line, neither of which was in the Power BI reference, and we had to strip them back out. The lesson that generalises: check the reference for exactly what the element does and does not have before building it, because it is easy to spend an afternoon perfecting a detail that should not be there at all.

Getting the sizing right

This one is deceptively fiddly. A KPI card holds a label, a large value, a comparison line and the sparkline, and getting them to share the horizontal space cleanly is a CSS layout problem you own entirely. Our sparklines initially rendered cramped and mis-proportioned because the text block and the chart were fighting over the available width.

The fix was in how the flex layout distributed space: letting the text block take its natural width without stretching, and giving the sparkline a flexible share of what remained, then sizing the chart’s internal drawing area to match its actual rendered box rather than a guessed nominal size. If the drawing area’s dimensions and the on-screen box disagree, the line renders distorted. Matching them is what makes a sparkline look intentional rather than squeezed. This is ordinary web layout work, but it is work Power BI never asked you to do.

Above is the Fabric Apps KPI cards, below is the Power BI KPI cards
The sparkline sharing card width cleanly with the value and comparison line. All hand-tuned CSS.

Months in alphabetical order (the one that cost us the most)

This is the standout gotcha, and it is worth telling in full because you cannot look it up.

Our trend charts came out with the months along the x-axis in alphabetical order, April, August, December, January, rather than chronological. This is a classic charting problem with a classic fix: tell the chart to sort the axis by the month’s actual order. So we set the sort property. Nothing changed. We set it a different way. Still nothing.

The cause turned out to be that the Fabric visual component silently ignores Vega-Lite’s sort property. It does not throw an error, it does not warn, it simply does nothing with that instruction. Every hour we spent adjusting the sort was spent on a control the platform was quietly discarding.

The fix, once we understood the cause, was to stop trying to sort at all. Instead we encoded the x-axis on a numeric month index, one through twelve, so the chart orders points by a real number, and then generated the visible month labels separately from that index. Order by numeric encoding, never by the sort property. That single sentence is now a permanent note in our build guide, and if you take one concrete thing from this article, let it be that: on this platform, do not trust sort on a chart axis, encode order as a number.

Abbreviating and rounding numbers

Power BI shows 55.56M and $800K and 51.27% because its formatting engine abbreviates and rounds for you, per visual, from a dropdown. A Fabric App renders exactly the number you hand it. If you pass a raw revenue figure into a KPI card, you get every digit.

So number presentation becomes your code. You decide where to abbreviate to millions or thousands, how many decimal places each context carries, where the currency symbol and percent sign go, and how the axis ticks read ($5.0M, $10.0M rather than 5000000). The trap here is inconsistency: it is easy to abbreviate one card to two decimals and another to one, or to round a KPI differently from the axis it sits above, and the page then looks subtly untidy in a way that is hard to pin down. The cure is to centralise formatting, decide the rules once, in one place, and route every displayed number through them, rather than formatting each value where it happens to be rendered. That way “millions to two decimal places with a leading currency symbol” is defined once and applied everywhere.

Below is an Fabric Apps Revenue trend:

Below is the Power BI revenue trend.

Formatting the rest of the look

Beyond numbers, a pile of smaller visual details each needed a deliberate decision that Power BI would have defaulted for you. The prior-year line being dashed rather than solid to distinguish it from actuals. The trend y-axes starting at zero on the revenue and cost charts, but deliberately staying zoomed on the net-margin chart so a one-percent movement is visible. Removing the vertical gridlines while keeping the horizontals. The area fill, or absence of it, under each trend line. None of these is hard. Collectively they are the difference between a page that looks like a finance report and one that looks like a developer’s first draft, and every one is a line of configuration you write rather than a property you toggle.

Below is the Fabric Apps charts

Below is the Power BI version

The honest verdict: Power BI is quicker for a report

Here is the conclusion we reached, stated plainly because it is the most useful thing for anyone weighing this up.

Building a report is faster in Power BI. It is not close. Every visual we have described, the sparkline, the formatted numbers, the correctly ordered months, the dashed comparison line, is something Power BI delivers with a few clicks and a Fabric App makes you construct by hand. If the deliverable is a report that people read, rebuilding it as a Fabric App is spending a lot of engineering effort to arrive back where Power BI already was.

That is not a criticism of Fabric Apps. It is a statement about what they are for. A Fabric App is a web application that happens to sit on your semantic model, and its value is that it can do the things a report fundamentally cannot: guide a user through a specific decision path, or, most powerfully, let a user write data back and have it recalculate and persist. The reporting layer is not the point of a Fabric App. It is the familiar surface you rebuild so that the unfamiliar, genuinely differentiating capability has somewhere to live.

So the decision rule we would offer is simple. If you need a report, build it in Power BI. If you need an application that includes reporting as one part of something larger, a Fabric App is the right tool, and this guide is your map to the reporting-replication tax you will pay to get there. Go in knowing that the tax is real, that most of it is paid in small rendering details rather than big architectural problems, and that at least one of those details, the silently ignored sort, will cost you an afternoon unless someone warns you first. Consider yourself warned.

To learn more about Microsoft Fabric and how we can help with Fabric Apps, see our Microsoft Fabric page.

The post Replicating a Power BI report in a Microsoft Fabric App appeared first on Data Bear.

Six hours into the Health Check we had found three issues. None of them new. None of them visible from the report itself. All three of them already sitting on the internal list we keep of the patterns we see almost every time.

We have run more than 200 Power BI Health Checks since 2018, across financial services, retail, public sector, manufacturing, and healthcare. Different industries, different team sizes, different model complexities. The same three issues come up almost every time. This piece walks through what they are, why they recur, and what we recommend.

1. Auto date/time hierarchies left on

What it looks like

Open File > Options > Current File > Data Load in Power BI Desktop and find the Time intelligence section. If “Auto date/time” is ticked, Power BI silently generates a hidden date table behind every date column in the model. We have audited models that contain fourteen date columns. The model is carrying fourteen hidden date hierarchies, each one indexing every day from the start of the data to the end of next year.

 Power BI Desktop > File > Options > Current File > Data Load > Time intelligence. The toggle is on by default.

You will not see these tables in the model view. You will see them if you open the model in DAX Studio or Tabular Editor, or if you look at the .pbix file size and wonder why a model with twelve million rows of fact data weighs four gigabytes.

Why it matters

On the manufacturer’s model, switching auto date/time off and substituting a single date dimension cut the .pbix from 1.8 GB to 640 MB. Refresh time fell from forty-one minutes to twelve. The dashboard met its SLA again the following Monday.

The cost is rarely about disk space, though. It is about the VertiPaq engine doing more work than it needs to during refresh, and about the model carrying compression overhead that buys it nothing. On a Premium capacity, that overhead costs money. On a Pro tenant, it costs you users who close the dashboard and open Excel.

What we recommend

Auto date/time is on by default in every new Power BI Desktop install, and that default has not changed. So the first move is to turn it off at the file level (File > Options > Current File > Data Load > Time intelligence) for every new model. For existing models, turn it off in the same place and replace it with a single, marked date dimension. If you need to keep auto date/time on for one specific dataset, which is occasionally the right call for a sandbox or experimentation model, make that an explicit decision rather than an inherited default.

2. Bidirectional relationships used as a workaround

What it looks like

In the model view, any double-headed arrow between two tables. Sometimes one. Sometimes seven. Each one is a sign that someone, at some point, found a filter that would not propagate the direction they needed, switched the relationship to bidirectional, watched the visual update correctly, and moved on.

An anonymised model from a recent Health Check. The double-headed arrows are bidirectional relationships. Seven of them, in this case.

The visual updated correctly because bidirectional cross-filtering brute-forces the engine into propagating filters in directions it would not otherwise go. It also creates relationships that mask missing bridge tables, ambiguous join paths, and assumptions that fall apart the moment someone adds a new measure.

Why it matters

Bidirectional relationships are the single most common cause of the “this visual is taking too long to load” warning we see in Performance Analyzer. On a retail client’s sales model, removing four bidirectional relationships and replacing two of them with bridge tables took a slicer-driven page from nine seconds to under two. The page had not changed; the user could not tell us what we had done, only that it now responded the moment they clicked. That is the kind of fix that earns a Health Check its fee, because it is invisible until someone measures it.

 Performance Analyzer on the same page before and after the fix. Total query duration on the right.

Performance is only the visible half of the cost. Bidirectional relationships are also the most common cause of ambiguity errors that surface months after a model goes live, when someone adds a measure that crosses the wrong filter path and Power BI flags the calculation as ambiguous. The error is technically correct. The model has been wrong for months, and the new measure is simply the first thing to ask a question the broken filter path could not answer.

Why it keeps happening

Bidirectional cross-filtering is a one-click change in the modelling pane, and it usually fixes the immediate symptom on the spot. The underlying cause, which is almost always a missing bridge table or a many-to-many that the data layer should have resolved, requires more thought and does not show its payoff on the screen in front of you.

Microsoft’s documentation now warns against the pattern in several places, but those warnings live deep inside longer modelling articles. The user never sees them at the moment of the click, which is the only moment that would change the decision.

What we recommend

Treat every bidirectional relationship as a flag, not a fix. If your model has more than one, write down what each one is doing and what would break if it were single-directional. In almost every case, the right answer is a bridge table, a measure that uses CROSSFILTER inside its calculation, or a remodel of the underlying schema.

3. Calculated columns doing the work of measures

What it looks like

A model with thirty, forty, sometimes more than a hundred calculated columns. Sales margin as a column. Year-on-year change as a column. Customer lifetime value as a column. The engine computes each one row by row during refresh, stores it uncompressed (or close to it) in the model, and gains nothing at query time because every source refresh recomputes the column anyway.

 VertiPaq Analyzer in DAX Studio, sorted by column size. Calculated columns in the top ten are the ones we focus on first.

The giveaway is the calculation icon next to the column name in the field list. The cost stays hidden until you look at the storage tab in DAX Studio and find that a third of the model size has gone to columns that should have been measures.

Why it matters

Calculated columns sit at the wrong end of every Power BI performance trade-off. They bloat the model. Their values are often unique or near-unique per row, so compression is poor. Visuals cannot reuse them the way measures can. Refresh time grows with every column added, because the engine recomputes each one whenever the source refreshes. And the work happens at refresh, when the VertiPaq engine could do it faster at query time through a measure.

On a financial services client’s general ledger model, converting twenty-three calculated columns into measures reduced model size by 38% and brought refresh time down by nine minutes. The measures themselves added negligible query time, because the engine aggregates at speed.

Why it keeps happening

Calculated columns feel intuitive to anyone who has spent time in Excel. They look like spreadsheet formulas. They produce a column you can see, drag, and filter. Measures, by contrast, only exist when something asks for them. So new Power BI developers learn calculated columns first, build their first three or four models around them, and never revisit the choice.

Where you actually want a calculated column

There are cases where a calculated column is the right tool, and they are worth naming so the rule does not harden into dogma. You want one when the value participates in a relationship, when users will filter or group on it directly, or when it feeds a slicer a measure cannot. Everything else should default to a measure. To find the columns that broke that rule, sort your model’s columns in DAX Studio by storage size and walk down the list, asking of each whether it could be a measure instead. Most of them can be.

What to do before you bring anyone in

Three checks you can run against your own model this afternoon:

1. Open File > Options > Current File > Data Load. If “Auto date/time” is on, turn it off, then check each existing model in the tenant.
2. Open the model view. Count the bidirectional relationships. For each one, write down what would break if it were single-directional. Any one you cannot answer is a flag.
3. Open DAX Studio against your largest model. Run VertiPaq Analyzer. Sort columns by size. If calculated columns appear in your top ten, you have at least one conversation worth having.

If any of these return more than you expected, you have somewhere to start.

Why the Power BI Health Check still finds these three

These three issues have been in our top three for six years. Power BI has changed in that time, the licences have changed, and Microsoft has rebranded the products more than once. The underlying patterns have not changed.

Part of the reason is that Microsoft ships defaults that are friendly to a first-time user and costly to a mature one, and Power BI’s user base has matured faster than the defaults have. Part of it is that the path from “I built a working dashboard” to “I built a healthy dashboard” is not a path most teams know they need to walk. The dashboard works. The questions get answered. The cost shows up later, usually as a refresh that started missing its window.

Some of the harder decisions sit upstream of the model itself, in where data preparation lives and what the pipeline architecture should look like. We have written separately about whether you need a silver layer in Power BI, which is often the next conversation after a Health Check, when the answer to “fix the model” turns out to be “the model is the wrong place to fix it.”

A Power BI Health Check is one way to catch the cost early, particularly where these three patterns sit underneath thirty more that an afternoon’s self-check will not surface. Running the three checks above against your own model, honestly, is the cheaper place to start.

The post The three issues that fail nearly every Power BI Health Check we run appeared first on Data Bear.

We started with the technical side. The semantic models were workmanlike. Properly modelled, sensible naming, reasonable size. Refreshes were failing not because of design issues but because nobody could agree which reports were still in use, so every developer was protecting every dataset.

That client had almost no model debt. They had a vast amount of adoption debt. They had also spent eighteen months hiring developers to fix it, which had not worked, which was why they had called us.

Most Power BI estates carry both kinds of debt. Almost none carry them in equal measure. Knowing which one you have more of is the difference between hiring a developer and hiring a programme manager, and the wrong choice will not work no matter how good the person is.

We have audited Power BI estates at more than 150 organisations over the last decade. This piece sets out what each kind of debt looks like, how to tell which one you have, and what we recommend doing about each.

Type 1: Power BI model debt

What model debt is

Debt in the technical foundations of your semantic models. Bidirectional relationships used as quick fixes. Calculated columns doing the work of measures. Auto date/time left on. Business logic that should live in the data layer, hardcoded in DAX instead. Manual data preparation steps that exist only in one developer’s head. Models that different people built grain by grain, without any shared design.

 A semantic model carrying significant model debt. Eleven tables, six bidirectional relationships, no obvious fact-and-dimension split.

What it costs you

Refresh times grow. New measures break old ones in non-obvious ways. Every change becomes a careful threading exercise through assumptions nobody has written down. Developers spend more time on operations than on building. The cost shows up as a slow drain on the team’s velocity, and as the unease that settles over any model that has lasted longer than its design intended.

A worked example

One engagement last year shows the shape of it. A logistics business came to us with a single semantic model that had grown over four years to forty-one tables. Refresh ran for fifty-three minutes and failed roughly one morning in five. Nobody on the team could say what most of the model did, because the two developers who had built it had both since moved on.

When we opened it in DAX Studio, the picture was familiar. Nine bidirectional relationships. A central fact table carrying thirty-one calculated columns, several of them recomputing values that already existed as measures elsewhere in the same model. Auto date/time had quietly generated hidden hierarchies behind nineteen separate date columns. None of this was visible from the reports, which looked fine, which was exactly why it had survived four years.

The fix was not glamorous. We marked a single date dimension and switched auto date/time off, which on its own took the model from 2.3 GB to 900 MB. We converted twenty-six of the calculated columns to measures and removed seven of the nine bidirectional relationships, replacing two of them with bridge tables. Refresh dropped to fourteen minutes and stopped failing.

The work took six weeks. Most of that was not the refactor itself but reconstructing what the undocumented logic was supposed to do, because you cannot safely change code when nobody can tell you what it was for. That recovery, not the rebuild, is where model debt charges most of its interest.

Five questions for your lead developer

Put them to whoever owns your largest model:

1. Could you onboard a new developer to that model in a week?
2. If your most experienced developer left tomorrow, would the model still be maintainable?
3. When someone adds a new measure, do you know with confidence which existing measures it touches?
4. If a stakeholder asks for a new calculation, is the answer “two days” or “two weeks”?
5. When you open the model in DAX Studio and look at VertiPaq Analyzer, is the top of the column-size list mostly tables you expected to see there?

If you hesitated on two or more, the model is carrying more debt than its surface suggests.

How you pay it down

Model debt is fixable with technical skill. You pay it down through audit, refactoring, and discipline going forward. Some of the work also sits upstream of the model itself, in where data preparation lives. We have written separately about whether you need a silver layer in Power BI, which is often the right starting point when the model is the wrong place to fix the problem. We will also publish a companion piece on the three issues that fail nearly every Power BI Health Check we run (link to be added once that post is live), covering the model patterns that account for most of the Power BI debt we see in practice.

Type 2: Power BI adoption debt

What adoption debt looks like

Debt in the people, processes, and governance around your Power BI estate. No clear ownership for each model or workspace. Reports that someone built once and then quietly abandoned. No retirement process. Training delivered as a one-off event and never refreshed. Workspaces with names nobody can explain and contents nobody has audited. Different departments answering the same question with different numbers, all defended.

 Report usage from a recent client audit, anonymised. The top ten reports account for 71% of views. Of the remaining 240, more than half had not been opened in the last quarter.

Why it costs more than it looks

High tool spend with low business outcome. Time spent reconciling versions of the same number instead of acting on what the number says. Decisions that rested on whichever data was easiest to find, rather than whichever data was most accurate. Senior stakeholders who lose confidence in BI and revert to Excel. Most expensively, the slow erosion of the assumption that anyone can trust the BI estate at all.

How to tell

Three questions for whoever runs the Power BI tenant:

1. Do you know which reports are actively used this quarter, and which are not?
2. If a senior stakeholder asks “what is our [headline KPI]?”, does everyone come back with the same number?
3. Is there a named owner for each production dataset?

A single uncomfortable answer here is enough. This is not a problem a better dashboard solves.

Why a developer can’t fix it

Adoption debt is harder than model debt because it is not technical. You pay it down through governance, ownership, and culture, none of which a developer can fix on their own. The fix requires sponsorship at a level above the BI team. Without it, the debt grows back faster than any individual can pay it down.

Why the two kinds of Power BI debt matter separately

Hiring a Power BI developer to fix adoption debt does not work. They will produce excellent dashboards that nobody owns, and the problem will simply move.

Hiring a programme manager to fix model debt does not work either. They will run useful governance forums about a model that fundamentally cannot bear the weight of the questions being asked of it.

The two kinds of Power BI debt also feed each other. Model debt produces adoption debt because users stop trusting numbers that arrive late or behave inconsistently. The reverse runs more quietly: where ownership is unclear, developers build defensively, and defensive modelling is how a clean model slowly takes on the complexity nobody chose.

The diagnostic question we put to clients on the first day of an audit is deliberately blunt: when you sit with your most expensive current Power BI problem, is the painful work mostly technical or mostly organisational? The honest answer tells you where to start.

What to do before you bring anyone in

Three checks you can run in an afternoon, one for each debt and one to compare them.

1. Pull a report usage list for the last 90 days from the Power BI admin centre. Sort by views. If your top ten reports account for less than 30% of total views, you almost certainly have adoption debt. If they account for more than 80%, the long tail is probably already self-correcting and your problem sits elsewhere.
2. Run VertiPaq Analyzer (in DAX Studio) on your largest model. Look at total model size, refresh time, and the number of calculated columns in the top ten by storage. If any of those raise a flag, you almost certainly have model debt.
3. Ask your three most senior Power BI users which report they trust the most. If they give different answers, you have a clue about both debts, and a useful place to begin the conversation that follows.

If you run all three and your answers are healthy on every count, congratulations. You are an outlier.

One reflection on Power BI debt after 150 audits

Clients who arrive convinced they have a model problem almost always have an adoption problem sitting behind it, and the reverse holds just as often. The harder question is which one to fix first.

In the consulting engagements where we lead this work, we start with whichever debt is currently blocking value. Sometimes that means a structural intervention to the semantic model and a six-week refactor. In other engagements, it is a governance conversation the organisation has postponed for three years. Occasionally it is a frank discussion with the sponsor about whether the BI team has the mandate it needs to do either.

The mistake we see most often is the same one in either direction: an organisation pours money into the kind of debt they are comfortable thinking about, because the other kind is harder to face. Model debt has the comfort of being technical and therefore fixable. Adoption debt has the comfort of being someone else’s job. Neither comfort survives the audit.

The post The two kinds of Power BI debt and how to tell which you have appeared first on Data Bear.

Enter layout containers  the secret to building modern, responsive Power Apps without writing formulas.

In this blog post, we’ll walk through:

• The difference between bad vs. good responsive app layouts
• How to use container templates effectively
• Aligning elements using horizontal and vertical containers
• A real-world layout replication using nested containers
• Pro tips for alignment, spacing, and responsiveness

Let’s demystify layout containers in Power Apps  and save you hours of work.

The Problem with Manual Layouts

Before discovering containers, many app builders (including experienced ones) tried to manage layout using complex formulas:

Width = App.Width * 0.66
X = SomeControl.X + SomeControl.Width + 10

This approach becomes fragile and unsustainable as your app scales.

For example, a “bad” home screen might look fine initially  until you rotate the device or view it on another screen size. Suddenly:

• Buttons disappear
• Images shift
• Navigation is misaligned

Responsive design breaks down fast.

What a “Good” Layout Looks Like  Without Formulas

By using layout containers, you can build a responsive design that adjusts automatically across screen sizes. With proper setup:

• Buttons stay centered
• Images scale properly
• Navigation remains intuitive
• No layout formulas are needed

This is possible thanks to container-based screen templates now built directly into Power Apps.

Getting Started with Container Templates in Power Apps

When creating a new screen, Power Apps offers containerized templates such as:

• Sidebar
• Header/Main
• Dashboard layouts

For a layout with a header, sidebar, image, and navigation buttons, the “Sidebar” template works perfectly.

Once added, inspect the Tree View to see the structure:

Screen
├── Screen Container
    ├── Header Container (Top)
    └── Bottom Container
        ├── Sidebar Container (Left)
        └── Main Container (Right)

Key Tip:

Don’t give up on containers because you can’t drag-and-drop like other controls. Instead:

• Use the Tree View to reorder
• Or use the right-click > Reorder > Move to start/end options

Horizontal vs. Vertical Containers Explained

Understanding directionality is crucial:

• Horizontal containers lay out items left to right
• Vertical containers stack items top to bottom

Use the properties panel to confirm the direction. Icons in the Tree View also help identify layout flow.

Aligning Images and Buttons Without Formulas

To resize and align images or buttons within containers, use:

• Align in container: Set to Stretch for full width
• Flexible height/width: Enable to auto-resize within available space
• Justify/Align: Vertically and horizontally center buttons
• Gap: Control spacing between items (e.g., 10px between buttons)

You can now center multiple buttons, align images perfectly, and ensure responsiveness  without touching a single formula.

Real-World Layout Replication: Building a Booking App UI

Let’s recreate a professional layout inspired by a hotel booking web app, using nested containers.

Step 1: Set Up a Vertical Screen Container

• Add a vertical container to fill the entire screen
• Set a background color (e.g., pale blue)
• Rename logically: ScreenContainer

Step 2: Add a Main White Container Inside

• Insert another vertical container
• Set background: white
• Add padding: 15px top/bottom, 30px sides
• Rename: MainContainer

Designing a Responsive Three-Part Header

To create a header with:

• A logo (left)
• Action buttons (center)
• User info (right)

Nest three horizontal containers inside your main header container:

MainHeaderContainer
├── LeftHeaderContainer (Logo)
├── MidHeaderContainer (Buttons)
└── RightHeaderContainer (User Info)

Use alignment and padding settings to:

• Center items vertically and horizontally
• Add gap spacing between buttons
• Adjust container height manually if needed

Creating the Working Area: Filters, Data, and Details

Below the header, add a horizontal container:

• Left: Filtering and gallery
• Right: Image and additional info

Nest containers as follows:

WorkingAreaContainer (Horizontal)
├── LeftWorkingContainer (Vertical)
│   ├── FiltersContainer (Gray background, horizontal)
│   └── GalleryContainer (White, with data)
└── RightWorkingContainer (Vertical)
    ├── SelectedItemDetails
    └── Image or Actions

Use minimum height, padding, flexible width, and drop shadows to polish the layout and improve visual hierarchy.

Final Touches: Fully Responsive and Formula-Free

Once completed, your app will:

• Adjust to device orientation
• Auto-center buttons and images
• Handle resizing with grace
• Require zero formulas for responsiveness

You’re left with a professional, modern UI  without the layout headaches.

Best Practices for Using Layout Containers

Here are some tips to streamline your development:

Use container templates when possible
Rename containers logically for better readability
Understand directionality (horizontal vs. vertical)
Leverage flexible sizing and alignment settings
Use Tree View for reordering controls
Minimize formulas use container properties instead

Want to Level Up Your Power Platform Skills?

If you’re serious about designing better Power Apps, improving data visuals in Power BI, or mastering the Microsoft Power Platform  structured training can make all the difference.

Check out Data Bear’s Power BI Training for hands-on, real-world courses designed to elevate your Power BI and reporting skills.

Conclusion: Layout Containers Save Time & Sanity

Power Apps containers aren’t just a nice-to-have  they’re essential for building responsive, user-friendly Canvas Apps. Once you understand how to structure, align, and nest containers effectively, you’ll:

• Stop writing redundant formulas
• Design apps that work on all devices
• Save hours of development and debugging

The post Power Apps Layout Containers for Responsive Design appeared first on Data Bear.

Streamline Power BI Report Design with a Visual Theme Generator

Creating a consistent design across many Power BI reports can be difficult. In the past, theme customization often required manual JSON editing, which made the process slow and technical. However, this updated tool simplifies Power BI theming for both beginners and advanced users.

Key Features

Live Visual Editor

Users can instantly see theme changes applied to visuals in real time. As a result, report design becomes faster and more interactive.

Ready-to-Use Templates

Prebuilt layouts and backgrounds help users start quickly. In addition, these templates improve consistency across reports.

Organized Property Management

An alphabetical search makes styling options easier to find. Therefore, users spend less time searching through settings.

PBIP Compatibility

The tool fully supports Power BI Project (PBIP) files, making it easier to manage enterprise reporting projects.

Built-in Code Editor and Validator

Advanced users can still fine-tune JSON manually. At the same time, built-in validation helps reduce errors before deployment.

Preview Mode

Users can test themes on existing reports before saving changes. Consequently, teams can avoid design mistakes and maintain quality standards.

Overall, this tool greatly improves the report design process. Not only does it save time, but it also helps organizations maintain a clean and professional reporting experience.

Secure External Sharing for Power BI

Sharing Power BI reports with clients, vendors, or external users has traditionally been difficult. Furthermore, many organizations struggle to balance accessibility with security. To solve this challenge, a new embedded analytics solution now provides a secure and polished way to distribute Power BI content externally.

Core Capabilities

In-App Report Rendering

Users can view both standard and paginated Power BI reports inside one centralized interface. As a result, navigation becomes simpler and more user-friendly.

Personalized User Experience

End users can save bookmarks, customize layouts, and organize dashboards based on their preferences. Therefore, reports become more interactive and useful.

Editable Reports

Reports can also be edited directly within the application. This feature is especially valuable for collaborative client environments.

Paginated Table Builder

Users can create filterable and exportable reports directly from semantic models. In addition, this allows teams to generate custom tables without extra development work.

Brand Customization

Organizations can create white-labeled, multi-tenant experiences that match their branding. Consequently, businesses can deliver a more professional client experience.

By combining secure sharing with flexible analytics, this solution supports modern reporting needs while improving collaboration and usability.

Why These Updates Matter

Together, these Power BI and Microsoft Fabric innovations help organizations improve both report design and external collaboration. On one hand, the visual theme generator simplifies branding and consistency. On the other hand, the external sharing accelerator improves security and user experience.

As analytics environments continue to grow, tools like these become essential for scalable and professional reporting solutions.

Elevate Your Power BI Skills

If you want to improve your Power BI expertise and learn how to use these tools effectively, explore the training resources below:

Power BI Training from Data Bear

Whether you are just getting started or expanding an enterprise analytics environment, expert-led training can help you build cleaner, more effective, and more impactful Power BI solutions.

The post Power BI Theming and External Sharing Tools in Microsoft Fabric appeared first on Data Bear.

In this guide, we’ll walk through how to:

• Create a data model for Power Pages
• Automatically generate tables and relationships
• Customize your schema
• Add sample data for testing
• Prepare your application for real data integration

Power BI Training Resource

Prerequisites

Before diving in, ensure you have:

• A Power Pages site already created and deployed
• Access to Microsoft Dataverse
• Visual Studio Code installed
• Necessary Power Platform permissions

This tutorial builds on previous steps where the website has already been set up and deployed.

Why Data Modeling Matters in Power Pages

At this stage, your Power Pages site may still rely on placeholder or mock data. A proper data model enables:

• Structured data storage
• Scalable application architecture
• Seamless integration with APIs and external systems
• Better reporting and analytics (including Power BI integration)

Step 1: Generate a Data Model Using VS Code

Power Pages allows you to quickly scaffold a data model using built-in commands.

Run the Data Model Setup Command

In Visual Studio Code, execute:

/setup data model

This command will:

• Analyze your existing application
• Recommend a set of tables
• Generate an Entity Relationship Diagram (ERD)
• Create relationships between tables
• Prepare the schema for deployment

You’ll be prompted to confirm permissions and answer a few configuration questions.

Step 2: Review and Customize the Generated Tables

Once the process runs, an HTML preview will display the proposed data model.

Example Tables Created

The system typically generates tables such as:

• Service Categories
• Service Requests
• Service Request Notes
• Attachments
• Contact (existing table)

Key Customizations

Before finalizing, review and adjust:

1. Prefix Naming Convention

Instead of default prefixes, define your own (e.g., PW for your organization).

2. Column Data Types

For example:

• Change Request Number from text → Auto Number
• Add meaningful prefixes (e.g., SR-0001)

3. Field Validation

Ensure fields like:

• Titles
• Descriptions
• Relationships

…match your business logic.

Step 3: Approve and Deploy the Data Model

Once satisfied:

• Approve the schema
• Allow the system to create tables
• Wait for validation and deployment (this may take several minutes)

During deployment, the system:

• Runs pre-checks
• Creates tables in Dataverse
• Establishes relationships
• Publishes the schema

Step 4: Create a Solution in Power Apps

To manage and deploy your components efficiently:

1. Go to Power Apps
2. Navigate to Solutions
3. Create a new solution
4. Define:
   • Publisher
   • Prefix (e.g., PW)

Why Use Solutions?

Solutions help you:

• Move assets from Dev → QA → Production
• Package tables, apps, and components
• Maintain version control

Step 5: Add Tables to Your Solution

After deployment:

• Add existing tables using your prefix (e.g., PW)
• Include all related objects

This ensures everything is centrally managed.

Step 6: Build a Model-Driven App

To visualize and interact with your data:

1. Create a Model-Driven App
2. Add pages using Dataverse tables
3. Include:
   • Newly created tables
   • Contact table

This app acts as a quick interface to validate your data model.

Step 7: Populate Sample Data

To test your model, generate mock data using:

/add sample data

Configuration Options:

• Select tables (or all tables)
• Define number of records (e.g., 5 per table)

What Happens Next:

• The system validates prerequisites
• Inserts sample records
• Links related data automatically

You’ll start seeing:

• Service categories populated
• Service requests generated
• Relationships reflected in real time

Step 8: Validate Data in Your App

Open your model-driven app and:

• Refresh tables
• Verify records are being populated
• Check relationships between entities

This confirms your data model is functioning correctly.

Important Best Practices

1. Backup Regularly

At each stage:

• Export your solution
• Save a ZIP backup
• Use source control if possible

2. Validate Data Types Early

Incorrect data types can cause issues later when integrating APIs or Power BI.

3. Use Meaningful Naming Conventions

Consistent prefixes and naming improve maintainability.

4. Monitor Automated Processes

The system may retry failed steps automatically review logs when needed.

What’s Next?

At this point:

• Your data model is complete
• Tables and relationships are deployed
• Sample data is available

However, your Power Pages site is still not connected to this data.

Upcoming Step:

In the next phase, you will:

• Bind your data model to your website
• Use APIs (such as Web API)
• Replace mock UI with real, dynamic data

Conclusion

Creating a data model in Power Pages using Dataverse is a powerful way to accelerate development while maintaining flexibility and scalability. By leveraging automated tools and customizing where needed, you can quickly move from a static website to a fully data-driven application.

This foundational step sets you up for:

• Real-time data interaction
• Integration with Power BI
• Enterprise-grade application development

The post Power Pages Data Model Step-by-Step Guide appeared first on Data Bear.

This feature allows Power BI administrators to centrally manage report themes and make them available to every report developer in the organization. Even better, these themes can now be applied to Copilot-generated reports, ensuring consistent branding across manually created and AI-generated reports alike.

In this article, we’ll walk through:

• What Organizational Themes are
• Why they matter
• How to configure them
• How to use them in Power BI Desktop and Power BI Service
• How they integrate with Copilot
• Best practices for enterprise branding

If you want to improve your Power BI skills even further, check out this Power BI training resource from DataBear Power BI Training.

What Are Organizational Themes in Power BI?

Organizational Themes are centrally managed Power BI theme files that administrators can publish through the Power BI Admin Portal.

Instead of sending JSON files manually between developers, organizations can now:

• Store approved themes centrally
• Make themes available across the organization
• Standardize report branding
• Ensure visual consistency
• Apply themes to Copilot-generated reports

This feature significantly improves governance and branding consistency in enterprise Power BI environments.

Why Organizational Themes Matter

Before this feature existed, many organizations relied on:

• Email attachments
• Shared folders
• SharePoint repositories
• Teams chats
• Manual imports

This created several common problems:

• Developers used outdated theme files
• Reports lacked visual consistency
• Branding standards were difficult to enforce
• New team members struggled to find the correct theme

Organizational Themes solve these issues by creating a single source of truth for report styling.

How to Add an Organizational Theme in Power BI

To configure Organizational Themes, you need access to the Power BI or Microsoft Fabric Admin Portal.

Step 1: Open the Admin Portal

Inside Microsoft Fabric or Power BI Service:

1. Navigate to the Admin Portal
2. Locate Organizational Themes

This section allows administrators to upload and manage theme files centrally.

Step 2: Upload Your Theme JSON File

Once inside the Organizational Themes section:

1. Click Add Organizational Theme
2. Browse for your Power BI JSON theme file
3. Upload the file

The uploaded JSON file becomes available for organizational use.

Step 3: Add a Description

Provide a clear description for the theme.

For example:

• Corporate Branding Theme
• Executive Dashboard Theme
• Finance Department Theme
• Dark Mode Reporting Theme

This helps developers identify the correct theme quickly.

Enabling Organizational Themes for Copilot

One of the most exciting additions is the ability to use Organizational Themes with Power BI Copilot.

When uploading the theme, administrators can enable a toggle that allows:

• Copilot-generated reports
• AI-created report pages
• Automated visual layouts

to automatically inherit the organization’s branding.

This ensures AI-generated reports align with:

• Corporate color palettes
• Typography standards
• Visual formatting guidelines

Without this feature, Copilot-generated reports may look inconsistent with the rest of the organization’s reporting ecosystem.

Important: Enable the Theme Gallery

After uploading the theme, there is one critical step many users miss.

By default, the uploaded theme is initially disabled.

To activate it:

1. Click the ellipsis (…) next to the theme
2. Select Enable for Theme Gallery

Once enabled, the theme becomes visible to report developers throughout the organization.

Using Organizational Themes in Power BI Desktop

After enabling the theme, developers can immediately access it inside Power BI Desktop.

How to Apply the Theme

Inside Power BI Desktop:

1. Open your report
2. Navigate to View
3. Select Themes
4. Locate Organizational Themes
5. Choose the uploaded theme

The report instantly adopts the organization’s branding.

This includes:

• Colors
• Fonts
• Visual styles
• Background settings
• Formatting standards

One impressive aspect of this feature is that Power BI Desktop updates dynamically without needing to restart the application.

Using Organizational Themes in Power BI Service

Organizational Themes also work directly inside Power BI Service.

Applying Themes in Existing Dashboards

To apply a theme in the Service:

1. Open your dashboard or report
2. Click Edit
3. Navigate to View > Theme
4. Select your Organizational Theme

The report updates instantly with the centralized branding.

This is particularly useful for:

• Executive dashboards
• Shared workspaces
• Departmental reporting
• Enterprise analytics portals

Using Organizational Themes with Copilot

The integration with Copilot is where this feature becomes especially powerful.

Creating a Copilot-Generated Report

Here’s how it works:

1. Open a semantic model
2. Click Create Report
3. Launch Copilot
4. Enter a prompt such as:
   • “Create a sales performance versus targets report”

Copilot generates:

• Visuals
• Layouts
• KPIs
• Charts
• Report pages

And now, thanks to Organizational Themes, those generated reports automatically follow your organization’s branding guidelines.

This dramatically reduces cleanup work after Copilot generates a report.

Common Issue: Transparency Settings

One issue highlighted during testing involved transparency settings not behaving as expected.

In some cases:

• Visual backgrounds appeared partially transparent
• Formatting differed slightly from the original theme

Fortunately, this can usually be corrected by:

• Resetting the theme to default
• Reapplying the organizational theme
• Adjusting transparency manually

Since Organizational Themes are still in preview, occasional inconsistencies are expected.

Benefits of Organizational Themes

1. Centralized Governance

Administrators maintain full control over approved themes.

2. Consistent Branding

Every report follows the same visual standards.

3. Faster Report Development

Developers no longer waste time searching for theme files.

4. Improved Copilot Integration

AI-generated reports automatically match company branding.

5. Better User Experience

Executives and stakeholders see a consistent reporting environment.

Best Practices for Organizational Themes

To maximize the value of this feature:

Standardize Naming Conventions

Use clear names such as:

• Corporate Theme v1
• Executive Reporting Theme
• Sales Analytics Theme

Maintain Version Control

Keep backup copies of your JSON files in source control systems like:

• GitHub
• Azure DevOps
• SharePoint

Test Themes Thoroughly

Validate themes across:

• Desktop
• Service
• Mobile layouts
• Copilot-generated reports

Document Branding Standards

Create internal documentation covering:

• Color palettes
• Typography
• Approved visuals
• Accessibility requirements

Organizational Themes and Enterprise BI Strategy

This feature may seem small initially, but it represents a major advancement in enterprise Power BI governance.

As organizations scale their BI environments:

• Branding consistency becomes critical
• Self-service BI expands rapidly
• AI-generated reports become more common

Organizational Themes help bridge the gap between:

• Flexibility for developers
• Governance for administrators
• Consistency for stakeholders

Final Thoughts

Power BI Organizational Themes provide a smarter and more scalable way to manage branding across reports and dashboards.

Instead of manually distributing JSON files, organizations can now:

• Centralize theme management
• Standardize report design
• Streamline developer workflows
• Enhance Copilot-generated reports

For teams heavily invested in Power BI and Microsoft Fabric, this feature can significantly improve governance, efficiency, and visual consistency.

As Microsoft continues enhancing Copilot and AI-assisted analytics, Organizational Themes will likely become an essential part of modern Power BI development workflows.

Learn More About Power BI

If you’re looking to improve your Power BI development skills, dashboard design techniques, and reporting strategies, explore this excellent training resource from DataBear Power BI Training.

The post Power BI Organizational Themes Guide appeared first on Data Bear.