Technology context: Microsoft Power Platform - Power Apps, Dataverse, Power Automate/API services and Power BI Paginated Reports
Microsoft Power Platform makes it possible to implement business behaviour in many places.
A rule can be written in Power Fx inside a Canvas App. It can be represented in Dataverse. It can be implemented in a flow or API. It can even be embedded inside a Power BI Paginated Report expression.
That flexibility is valuable.
It also creates one of the most important architectural questions in a growing Power Platform solution:
Where should the business rule actually live?
Business logic needs an architectural home
The fact that a Power Platform component can implement a rule does not mean it should own it.
A useful default is:
- Power Apps owns interaction and user experience
- Dataverse owns persistent business data, relationships and reusable configuration
- APIs or automation own cross-system operations and orchestration
- Power BI and Paginated Reports primarily present already-resolved business meaning
These boundaries are not absolute.
But without them, business logic gradually spreads across the platform until no single layer clearly owns it.
Power Apps should own interaction, not enterprise truth
Canvas Apps naturally contain logic.
Power Fx controls field visibility, navigation, validation messages, filtering and user interaction.
That is appropriate.
Problems begin when an important business rule exists only inside one screen.
If the same rule is later required by another application, an import process, an API or a report, it must either be duplicated or reverse-engineered from the app.
The Power App should therefore own the experience.
Shared business meaning should usually live somewhere more reusable.
Dataverse can be more than storage
Dataverse is often treated simply as the database behind Power Apps.
That misses much of its architectural value.
When business behaviour depends on persistent entities, relationships or configuration, Dataverse can provide a natural source of truth.
Consider a solution supporting multiple business or report types.
Instead of hard-coding:
“for this type, display these inputs, these options and these measures”
inside Power Fx or RDL expressions, those relationships can be modelled explicitly in Dataverse.
The application then interprets governed configuration.
The report consumes resolved data.
Adding a new business variation can become a data/configuration change rather than a redevelopment exercise.
APIs and automation should own process boundaries
Power Automate, custom APIs, Azure Functions and other service layers become appropriate when the rule represents a business operation spanning multiple systems or consumers.
Examples include orchestration, external integration, controlled transformations and processes that must behave consistently regardless of which application initiated them.
The architectural test remains the same:
Does this rule belong to the business domain, or merely to this particular implementation path?
If it is domain configuration, Dataverse may be the better owner.
If it defines an operation across system boundaries, an API or automation layer may be more appropriate.
Reports should present decisions, not make them
Power BI Paginated Reports can contain surprisingly sophisticated expressions and custom code.
That makes it tempting to solve business problems directly in the RDL.
Initially, this can be efficient.
A condition becomes an expression. Another report type adds another branch. Narrative text begins to assemble itself dynamically from multiple input values.
Eventually, the report is no longer merely presenting information.
It is deciding what the information means.
That creates several problems:
the logic is difficult to reuse,
testing becomes coupled to report rendering,
business-rule changes require report deployment,
and another channel may calculate the same result differently.
A strong default is:
Resolve business meaning before the data reaches the report wherever practical.
The RDL should still own presentation concerns such as layout, grouping, visibility and formatting.
It should not become the primary business-rules engine.
Configuration is often better than repeated Power Fx branching
A Power App supporting several related business scenarios can easily accumulate conditions:
if type is A, show these controls;
if type is B, load these options;
if type is C, apply another set of rules.
That works initially.
It becomes harder to sustain as variations grow.
Where those differences are predictable, a Dataverse configuration model can define:
- applicable inputs
- available options
- measures or rules
- ordering
- active/inactive state
- relationships between business concepts
The Canvas App can then render behaviour dynamically from configuration.
The benefit is not simply less Power Fx.
It is the separation of business configuration from application implementation.
Centralisation is not the objective
Moving business logic out of Power Apps or reports does not mean putting everything into Dataverse.
That would simply create a different form of poor architecture.
Power Apps should continue to own UI behaviour.
Paginated Reports should own presentation.
APIs should own service boundaries.
Dataverse should own appropriate persistent business meaning and configuration.
Good architecture is not about concentrating logic in one technology.
It is about making ownership explicit.
A practical ownership test
When deciding where a rule belongs in Power Platform, ask:
Will another application or report need the same rule?
If yes, Power Fx may be too local.
Does the rule define business meaning or only presentation?
If it defines business meaning, the RDL may be too late.
Is the rule driven primarily by persistent configuration or relationships?
Dataverse may be the natural owner.
Does it coordinate multiple systems or consumers?
An API or automation layer may be more appropriate.
Would a business configuration change unnecessarily require redeploying the Canvas App or report?
If so, the model may be too hard-coded.
Closing perspective
Power Platform gives architects many places to implement logic.
That flexibility is powerful, but without clear boundaries it can also create fragmented systems.
The strongest solutions make ownership deliberate:
Power Apps manages interaction.
Dataverse preserves reusable business data and configuration.
APIs and automation manage service and process boundaries.
Power BI presents the result.
The important question is therefore not:
“Where is it easiest to write this rule?”
It is:
“Which Power Platform layer should remain accountable for this rule as the solution grows?”