Co-authored by

When to Use Power BI vs a Custom Application: The One Rule

Quick answer: If a user acts on it, it belongs in the application. If a user only looks at it, it belongs in Power BI. Nearly every argument about whether a feature should be a report or an app resolves in one sentence once you ask which of those two things the user is actually doing.

The question arrives in the same shape every time. A team is scoping an operations command centre — a surface where people watch what is happening across a network of sites, equipment, or crews and do something about it. Someone has drawn a wireframe with fourteen panels. Half the room says most of it is dashboards and belongs in Power BI; the other half says it is an application and Power BI is a reporting tool. Both sides reach for capability lists, and the meeting goes nowhere, because capability lists cannot settle it. Power BI can now write data. A custom app can obviously render a chart. Overlap is the whole problem.

The rule cuts through it by asking about the user rather than the platform. The rest of this post refines that sentence, tests where it breaks, and accounts honestly for what the March 2026 arrival of Power BI write-back did and did not change.

This is the hub of a short series on the same question. If you are still working out which product you are choosing between, start with whether Power BI is part of Microsoft Fabric and the Fabric versus Power BI decision framework. If you already know and are weighing hosting, Fabric Apps versus a custom web app prices both sides.

Dashboard vs Application: What "Acts On It" Really Means

Quick answer: "Acts on it" covers two things — changing state, and needing the information within seconds. A read-only panel that has to be current to the second is an application feature even though nobody clicks anything.

The plain rule handles the obvious cases and then fails on one class of feature: the live status board. Nobody types into it and nobody approves anything. It shows what is happening right now, and it has to be right right now, because someone is going to pick up a radio based on it. By the plain reading that is looking, so it is Power BI.

In practice it is an application feature, and Microsoft's own limits are the reason. Automatic page refresh — the mechanism that makes a report update itself without a human pressing anything — is documented as unsupported in Import storage mode entirely. On DirectQuery or Direct Lake in a shared workspace, the minimum interval is 30 minutes. You only reach a one-second floor on dedicated Fabric capacity, where the administrator sets a minimum that defaults to five minutes.

So the refinement is: if a user acts on it, or needs it within seconds, it belongs in the application. Both halves are about the user's relationship to time. Acting is a write within seconds; a live board is a read within seconds. Power BI is built to be excellent at neither, and that is not a defect — it is what makes it good at the thing it is for.

The corollary saves money: everything that does not need to be current to the second stays in Power BI even when it sits on the same screen as something that does. This month's utilisation against last month does not need a bespoke build. Embed it.

Does Power BI Write-Back Change the Answer?

Quick answer: It moves the line for single-record, low-frequency edits and leaves it exactly where it was for operational response. The slow leg of the loop was never the write — it was the notice.

Power BI can now write. Microsoft calls the capability translytical task flows, and its Power BI release archive records it as generally available in the March 2026 update, Desktop version 2.152.882.0: "Translytical task flows let end users take action directly from Power BI reports—updating records, adding data, or triggering workflows in other systems—without leaving the report." The preview labels came off the documentation on 12 March 2026. Write-back targets Fabric SQL databases, Fabric warehouses, and Fabric lakehouses for files.

This is real and useful, and it is routinely oversold in architecture reviews. The mechanism, from Microsoft's overview: a report author drops a button on the canvas, sets its action type to Data function, and points it at a Fabric user data function. Report elements — a slicer, a text input, a measure — map to that function's parameters. The user clicks; the function runs.

The constraints that follow from that design are what you plan against:

• The function must return a string. That is one of only two entries in Microsoft's Limitations section — the other being that Power BI Embedded is supported for secure embed scenarios only.
• Fabric capacity is a prerequisite, in a supported region. This is where GCC teams get caught, and I will come back to it.
• Service limits are inherited from user data functions: a 4 MB combined request payload, a 240-second execution timeout, and a 100-second timeout on public endpoint invocation.
• What the user sees next depends on storage mode — Microsoft's wording: updated values "appear immediately for Direct Lake or DirectQuery reports, or after an automatic refresh triggered by the task flow for import-mode reports."

None of that says "slow." A write-back round trip on a Direct Lake model can surface within seconds. The reason write-back does not turn Power BI into an operations application sits at the other end of the loop — how the user finds out something needs attention at all.

Classic Power BI data alerts fire at most hourly or at most daily, work only on gauges, KPIs and cards, cap at 250 across all your models, and — the load-bearing sentence — "alerts only work on refreshed data." On Power BI Pro a semantic model gets eight scheduled refreshes a day; on Fabric or Premium capacity, 48. Fabric Activator is the modern path and is better, but its Power BI connector queries the semantic model once per hour by default, and Microsoft notes plainly that "querying more frequently than the semantic model refreshes provides no benefit."

Activator against a real-time eventstream is a different story — subsecond for stateless rules, with end-to-end latency Microsoft caps at "up to 10 minutes" in the awkward cases. But that is Real-Time Intelligence doing the noticing, not a report. The button that writes is not the bottleneck. Getting a human to the button is.

Should This Be a Report or an App? Ten Features, Worked

Quick answer: Roughly half of a typical command-centre wireframe is Power BI, a third is unambiguously application, and the arguable middle is where write-back earns its place.

Run the rule across a realistic feature set. The last column is the reason, not a restatement.

The two write-back rows share a shape: a single record, a single field, and a cadence measured in days or months rather than seconds. That is the envelope. Push past it — a second field, a second actor, a state machine, an SLA — and you are building an application inside a report, which is the most expensive way to build an application.

Row eight is deliberately unresolved: whether an API call belongs in the report depends on whether the person triggering it was already reading one when they decided to.

The Five-Step Loop That Decides Your Architecture

Quick answer: Notice, surface, understand, respond, remember. Power BI owns understanding and remembering outright, the application owns noticing and responding, and surfacing splits by how fast it has to happen.

Every operational system runs the same loop. Mapping a proposed feature onto it is faster than arguing about platforms.

1. Notice — something crossed a threshold. This is detection cadence, where BI alerting is weakest by design. Application, or Real-Time Intelligence.
2. Surface — get it in front of someone who can act. Split: a daily digest is Power BI, a live board is not.
3. Understand — what is the history, what is normal, what else is happening. Power BI, and it is not close.
4. Respond — do the thing. Write-heavy, contended, second-critical. Application.
5. Remember — what was done, by whom, whether it worked. Power BI reads it; the application writes it.

Two things fall out of this that teams get backwards. Steps 3 and 5 are the majority of the value and a minority of the engineering — reaching for a custom build there means hand-rolling time intelligence, row-level security, and a refresh pipeline Power BI already ships.

And step 5 is not free. Remembering requires that step 4 wrote a record somewhere queryable. Teams design the response step as a button that calls an API, forget to persist what happened, and discover six months later that the command centre cannot answer "how long do we take to respond?" — the one question its budget was justified on. Design the audit table with the action, not after it.

When Is Power BI Not Enough — and When Is the Rule Wrong?

Quick answer: The rule breaks when the action is rare enough that an app is not worth building, when regional availability removes write-back from the table entirely, or when the organisation cannot operate two surfaces.

Four honest failure modes.

The action is genuinely rare. One field, once a month, one person. The rule says application; judgement says a write-back button and a Fabric SQL database. Take the judgement. The rule is a default, not a law.

Fabric capacity is not available where you are. Microsoft's region availability page, updated 28 July 2026, marks both UAE Central and Qatar Central as "Power BI only region" — the wider Fabric platform is not there, so Fabric SQL databases and user data functions are not either, and write-back is off the table at any price. UAE North carries full Fabric workloads with no exclusions listed. Direct Lake, which is what makes a write visible immediately, requires a Fabric capacity subscription — Pro or PPU alone will not do. Saudi Arabia does not appear in that table at all, which is undocumented rather than documented-as-absent, and worth a direct question to your Microsoft account team. For the capacity crossover maths, that is a separate calculation.

Two surfaces is an operational cost, not just a technical one. Splitting cleanly along the rule can mean an operator alt-tabbing during an incident. Embedding the Power BI content inside the application resolves this and is the right answer more often than teams expect — same reports, one window.

The write must be transactional. A user data function has a 240-second execution ceiling and no documented concurrency guarantee. For a regulated approval where two people must not both commit, the report is the wrong host regardless of how simple the action looks.

The rule earns its keep by being recitable. Anyone on a delivery team can hold "acts on it, or needs it within seconds" in their head and apply it live in a workshop. A decision framework nobody can remember is a document, not a framework.

Frequently Asked Questions

Q: Can Power BI write data back to a database?

Yes, since the March 2026 Power BI release. The capability is called translytical task flows, and Microsoft's release archive records it as generally available in Desktop version 2.152.882.0. A report author adds a button, sets its action to Data function, and binds it to a Fabric user data function that writes to a Fabric SQL database, warehouse, or lakehouse. Report elements supply the parameters. It requires Fabric capacity in a supported region, and the function must return a string.

Q: When is Power BI not enough for an operational system?

When users must act within seconds, when actions are contended between multiple people, when a workflow has more than one step, or when something must keep running while nobody has the report open. Alerting is the constraint that matters most: classic data alerts fire at most hourly and only on refreshed data, and Fabric Activator queries a semantic model once per hour by default. A Power BI Pro semantic model refreshes eight times a day. None of that supports an operator responding to a live event.

Q: What are the limitations of Power BI write-back?

Microsoft's Limitations section lists two: the user data function must return a string type, and Power BI Embedded is supported only for secure embed scenarios. The practical constraints sit in the inherited user data function service limits — a 4 MB combined request payload, a 240-second execution timeout, and a 100-second public endpoint invocation timeout — plus the requirement for Fabric capacity in a supported region. Microsoft documents no concurrency limit and no end-to-end latency figure, which means neither is something you can design against.

Q: How fast can a Power BI report show data after a write-back?

It depends on storage mode. Microsoft states that updated values "appear immediately for Direct Lake or DirectQuery reports, or after an automatic refresh triggered by the task flow for import-mode reports." Direct Lake requires a Fabric capacity subscription. For an Import model, the round trip is bounded by the refresh the task flow triggers, not by the write itself.

Q: Should a live status board be a Power BI report or a custom app?

A custom application, in nearly every case. Automatic page refresh is unsupported in Import storage mode and floors at a 30-minute minimum interval on shared capacity. Only on dedicated Fabric capacity can it reach one second, and there the capacity administrator sets a minimum that defaults to five minutes. A board operators respond to in real time needs a push-based application surface, with Power BI embedded alongside it for historical context.

Deciding where a feature lives is the architecture question that quietly sets a project's budget, and it rarely gets settled by comparing feature lists. Beyond The Analytics builds Power BI and Fabric platforms for UAE and Saudi enterprises, including the cases where the honest answer is that a dashboard is not the whole system. If you are scoping something like this, the four things people mean by "Fabric apps" is the next thing to read.