DIALOGE — L: Logic¶

Logic is the engine of a solution. It takes data, applies rules, makes decisions, and drives outcomes. Without logic, a solution is just a database with a screen in front of it.

TL;DR

Logic should live as close to the data as possible. Start with declarative business rules, then low-code plugins, then classic plugins — escalate complexity only when simpler mechanisms cannot meet the requirement. Centralise before you distribute. Every piece of logic must be owned, testable, and packaged in a solution.

Applies To

Audience: Solution Maker · Solution Engineer BOLT Tiers: Tier 1–4 (complexity escalates with tier) Maturity: Basic → Advanced Frameworks: DIALOGE

What Logic Means in DIALOGE¶

Logic is where business requirements become executable behaviour. It is where an organisation's rules, processes, and decisions are encoded into the solution — determining what happens when a record is created, when a condition is met, when a user submits a form, or when a scheduled process runs.

Logic is also where most technical debt accumulates. Rules duplicated across multiple apps. Processes buried in individual flows that nobody can find. Business logic that was changed in one place but not another. Calculations that live in a formula in a canvas app, in a plugin, and in a Power Automate flow — all slightly differently.

Well-designed logic is centralised, reusable, testable, and maintainable. It lives as close to the data as possible, is packaged in solutions, and changes in one place when the business rule changes. Poorly designed logic is a maintenance liability that grows harder to unpick as the solution scales.

Why Logic Placement Is the Most Important Decision¶

Where logic lives determines everything — maintainability, reusability, testability, performance, and governance. A calculation that belongs on a Dataverse table should not be duplicated in three canvas apps. A business rule that must fire regardless of how a record is updated should not live only in a Power Automate flow that triggers from one specific entry point.

Before writing a single line of logic, the right question is: where does this logic belong?

The Principles of Logic Placement¶

Principle 1 — Logic should live as close to the data as possible. Logic that validates, calculates, or enforces rules on data belongs in the data layer — Dataverse business rules, calculated columns, low-code plugins. This ensures the rule fires regardless of which app, flow, or API modifies the record. Logic that lives only in an app is bypassed by every other entry point.

Principle 2 — Logic should be centralised before it is distributed. If the same logic is needed in more than one place, it belongs in one place that multiple consumers call — a Custom API, a low-code plugin, a reusable flow. Duplication is the enemy of maintainability. When the business rule changes, it should change in one place.

Principle 3 — Logic should be owned. Every piece of business logic should have a named owner — the person or team responsible for it when it breaks or needs to change. Logic without an owner accumulates silently and becomes the technical debt that nobody wants to touch.

Principle 4 — Logic should be testable. Logic that cannot be tested cannot be changed with confidence. Design logic in units that can be validated independently — business rules that can be triggered in isolation, flows that can be run with test data, plugins that have unit tests. Enterprise solutions that grow without testable logic become brittle.

Principle 5 — Logic should be packaged. Logic belongs in solutions — versioned, deployable, and promotable across environments. Logic built directly in production, outside of solutions, is ungoverned, unversioned, and unrecoverable. This is where Logic meets Go-Live — see G — Go-Live for the full ALM treatment.

Principle 6 — Complexity should escalate deliberately. Start with the simplest logic mechanism that meets the requirement. Declarative business rules before low-code plugins. Low-code plugins before classic C# plugins. Native flow logic before custom rule engines. Escalate to more complex mechanisms only when simpler ones genuinely cannot meet the requirement — not because more complex feels more powerful.

Logic Placement Decision Table¶

Logic Type	Recommended Placement	Why
Field validation that always applies	Dataverse business rule	Fires regardless of entry point
Calculated value derived from other fields	Dataverse calculated column	Computed once at the data layer, available everywhere
Aggregate from related records	Dataverse rollup column	Maintained automatically, no flow required
Server-side logic in Power Fx without C#	Low-code plugin	Maker-accessible server-side extensibility
Complex server-side logic requiring C#	Classic Dataverse plugin	Full pro-code server-side control
Reusable business logic callable by multiple consumers	Custom API	Stable, governed, versioned contract
Multi-step process automation	Power Automate cloud flow	Orchestration across systems and services
Legacy UI or desktop automation	Power Automate desktop flow	RPA for systems without APIs
Client-side behaviour in model-driven app	JavaScript via Client SDK	UI-layer behaviour that server-side cannot address
Formula-driven app behaviour	Power Fx	Canvas app, model-driven app, Power Pages expressions
Guided user process across stages	Business process flow	Stage-gated process visible to the user
Highly complex, frequently changing rules	Third-party rule engine (North52, InRule)	Purpose-built rule management beyond native tooling
AI-driven decision or recommendation	AI Builder model in flow	Probabilistic logic requiring model inference

Declarative Logic — The Right Starting Point¶

Declarative logic requires no code — it is configured, not written. For the majority of field-level validation, calculation, and display behaviour, declarative mechanisms are sufficient and should always be the starting point.

Business Rules¶

Business rules are declarative logic applied at the Dataverse table level. They fire whenever a record is created or updated — regardless of which app, flow, or API triggered the change. This universality is their primary enterprise value.

Business rules can: - Set field requirements conditionally — make a field required when another field has a specific value - Set default values based on conditions - Show or hide fields based on other field values - Validate field values and display error messages - Lock fields to prevent editing under specific conditions

The enterprise implication: A business rule defined on a table is automatically enforced across every canvas app, model-driven app, Power Pages portal, and API interaction that touches that table. Define once, enforce everywhere. This is the correct architecture for rules that must always apply — not logic duplicated in each consuming app.

Business rule scope: Business rules can be scoped to execute on the server (enforced regardless of entry point) or on the client only (enforced in the UI but bypassable via API). For rules that must be enforced as data integrity constraints — always use server scope.

Calculated and Rollup Columns¶

Calculated columns derive their value automatically from other columns on the same record — or from related records via a simple expression. Common uses: full name concatenation, days since a date, status-derived labels, simple conditional values.

Rollup columns aggregate values from related child records — sum, count, average, min, max. Common uses: total order value across order lines, open case count on an account, average satisfaction score across survey responses.

Both column types compute their values at the data layer — available to every app, report, flow, and agent that accesses the table without requiring any additional logic in the consuming solution.

The performance consideration: Rollup columns are calculated on a scheduled basis (not in real time by default) and can be manually recalculated via a flow or plugin when real-time accuracy is required. Understand the calculation timing before relying on rollup columns for time-sensitive decisions.

Low-Code Plugins — Server-Side Logic for Makers¶

Low-code plugins are one of the most strategically important and underused capabilities in Power Platform. They bring server-side Dataverse extensibility to Solution Makers — without requiring C# or plugin registration tooling.

What they are: Low-code plugins are Power Fx-based logic that executes server-side within Dataverse — triggered by record events (create, update, delete) or called as Custom APIs. They run with the same transactional guarantees as classic C# plugins, but are authored in Power Fx and deployed as part of a solution without a development environment or compilation step.

Why they matter for enterprise: Before low-code plugins, server-side Dataverse logic beyond business rules required a professional developer writing C# plugins. This created a dependency bottleneck — every server-side logic requirement had to wait for a pro-code resource. Low-code plugins remove that bottleneck for a significant class of scenarios:

Enforce complex cross-field validation that business rules cannot express
Calculate values that require logic beyond what calculated columns support
Trigger actions when records change — without the latency and reliability limitations of a Power Automate flow
Expose business logic as Custom APIs callable from apps, flows, and external systems

Low-code plugins vs Power Automate flows: This is a decision that enterprise architects encounter frequently. The key distinction:

Concern	Low-Code Plugin	Power Automate Flow
Execution context	Synchronous, within Dataverse transaction	Asynchronous by default
Rollback on failure	Yes — participates in the record transaction	No — flow failure does not roll back the record change
Latency	Milliseconds — within the save operation	Seconds to minutes
Use case	Logic that must succeed or fail with the record save	Multi-step processes, cross-system orchestration
Authoring	Power Fx	Low-code flow designer

The rule: If the logic must succeed atomically with the record save — use a low-code plugin. If the logic is a subsequent process triggered by the record save — use a Power Automate flow.

Classic Dataverse Plugins — Pro-Code Server-Side Extensibility¶

Classic plugins are C#-based assemblies registered against Dataverse events — the full pro-code extensibility model for server-side logic. They predate low-code plugins and remain the right choice when logic complexity, performance requirements, or capabilities exceed what Power Fx can express.

When classic plugins are the right choice: - Complex algorithmic logic that Power Fx cannot express - Integration with .NET libraries or enterprise services not accessible via connectors - Performance-critical logic requiring precise control over execution - Pre-existing plugin codebase being maintained and extended

Enterprise governance considerations: Classic plugins execute within the Dataverse platform process — a poorly written plugin can destabilise an entire environment. Enterprise governance requirements for classic plugins: - All plugins must be version-controlled in source — no compiled assemblies deployed without a corresponding source commit - Plugins must be tested against a Dataverse sandbox environment before production deployment - Plugin registration and deployment must follow the standard ALM process — solutions, pipelines, approvals - Plugin performance must be profiled — synchronous plugins that execute slowly block the user's save operation

The escalation principle: Reach for classic plugins only when low-code plugins genuinely cannot meet the requirement. The authoring, testing, and deployment overhead of classic plugins is significantly higher. For most scenarios that previously required classic plugins, low-code plugins now provide a viable alternative.

Power Automate — Process Automation and Orchestration¶

Power Automate is the primary process automation and orchestration engine in Power Platform. Where Dataverse logic handles record-level behaviour, Power Automate handles multi-step processes, cross-system workflows, approvals, and scheduled operations.

Cloud Flows¶

Cloud flows are the core automation capability — event-triggered or scheduled logic that orchestrates actions across Power Platform and connected systems.

Flow types and when to use each:

Automated flows — triggered by an event (record created, email received, file uploaded). The workhorse of enterprise automation — process initiation driven by business events rather than manual action.

Instant flows — triggered manually by a user from a canvas app, model-driven app, or the Power Automate mobile app. Used when a process must be initiated on demand — generate a document, run a calculation, trigger an approval from a specific record.

Scheduled flows — triggered on a defined schedule. Used for batch operations, periodic synchronisation, maintenance tasks, and reporting processes.

The enterprise architecture principle for flows: Flows are orchestrators — they should call logic, not contain it. A flow that contains complex business logic is harder to test, harder to reuse, and harder to change than a flow that calls a Custom API or low-code plugin that contains the logic. Keep flows thin and logic centralised.

Approval Processes¶

Power Automate's approval capability is one of the most widely used enterprise patterns on the platform — and one of the most frequently over-engineered.

The native approval connector handles the majority of enterprise approval scenarios: single approver, sequential approvers, parallel approvers, and custom responses beyond approve/reject. Approvals appear in Teams, Outlook, and the Power Automate mobile app — meeting approvers where they already work.

Enterprise governance considerations for approvals: - Approvals should have defined timeout behaviour — what happens if an approver does not respond within the required timeframe - Approval chains that exceed four or five sequential approvers typically indicate a process design problem, not a technology limitation - Approval history should be stored in Dataverse for audit purposes — not just in the flow run history, which has a limited retention window - Delegated approval — when an approver is unavailable — should be designed explicitly, not discovered as a gap during an audit

Desktop Flows and RPA¶

Power Automate desktop flows provide robotic process automation — automating interactions with desktop applications, legacy systems, and web interfaces that do not expose APIs.

The enterprise RPA decision: Desktop flows are the right answer when a system cannot be integrated via API and the business process cannot wait for a system modernisation project. They are not a permanent architecture — they are a bridge. Every desktop flow should be documented as technical debt with a corresponding plan for API-based integration when the underlying system is upgraded.

Attended vs unattended: - Attended desktop flows run on a user's machine with the user present — suitable for augmenting manual processes - Unattended desktop flows run on a dedicated machine without user interaction — suitable for fully automated background processing, requiring an unattended RPA licence

Process Mining¶

Process mining analyses event log data to discover, visualise, and continuously monitor how business processes actually execute — not how they are documented to execute.

The enterprise value proposition: Before automating a process, organisations should understand the process as it actually runs — not as the process documentation describes it. Process mining surfaces the variants, bottlenecks, deviations, and inefficiencies that exist in real execution data. Automating a poorly understood process embeds its inefficiencies into the automation.

Power Automate process mining connects to event log data from enterprise systems — ERP, CRM, ticketing systems — and produces process maps, conformance analysis, and continuous monitoring dashboards. It is the discovery and optimisation layer that precedes automation investment, not an afterthought.

Power Fx — The Formula Language¶

Power Fx is the open-source, Excel-inspired formula language that spans the Power Platform — used in canvas apps, model-driven apps (business rules, command bars, visibility rules), Power Pages, Power Automate expressions, and low-code plugins.

Why Power Fx matters architecturally: Power Fx is the unifying logic language across the platform. A formula skill developed in canvas apps transfers directly to low-code plugins, model-driven app customisation, and Power Pages. This language consistency across the stack reduces the cognitive overhead of moving between product surfaces — a significant productivity advantage for Solution Makers building across multiple Power Platform products.

Power Fx principles for enterprise solutions:

Name everything — named formulas and variables over inline expressions everywhere. A formula named varCustomerRiskScore is maintainable; an inline expression three levels deep is not.
Avoid complex nesting — deeply nested If/Switch statements in a single formula are a maintenance liability. Break complex logic into named intermediate steps.
Delegation matters — understand which Power Fx functions delegate to the data source and which execute locally. Non-delegable queries against large Dataverse tables return only the first 500 records by default. Every canvas app accessing more than a few hundred records must be reviewed for delegation compliance.
Keep app logic thin — formulas that implement business logic which belongs in the data layer create duplication and maintenance overhead. Use Power Fx for UI behaviour; use Dataverse logic for business rules.

Client SDK — JavaScript in Model-Driven Apps¶

The Dataverse Client SDK provides a JavaScript/TypeScript API for customising model-driven app behaviour at the client layer — form logic, command bar actions, ribbon customisation, and event handlers that execute in the browser.

When the Client SDK is the right tool: - Dynamic UI behaviour that business rules cannot express — showing and hiding tabs, sections, or sub-grids based on complex conditions - Custom command bar buttons that trigger logic or navigate to specific views - Client-side validation with complex UI interaction — setting focus, scrolling to fields, displaying custom notifications - Calling Custom APIs from the form context and updating the UI with the response

Enterprise governance for Client SDK scripts: Client-side scripts execute in the user's browser — they are visible and debuggable by any user with browser developer tools. Do not embed sensitive logic, credentials, or business rules that must be enforced server-side in client scripts. Client scripts enhance the UI experience; server-side logic enforces business integrity.

All Client SDK scripts must be: - Version-controlled in source — no scripts deployed from browser editors - Included in solutions and deployed via the standard ALM pipeline - Tested across supported browsers before production deployment - Reviewed for performance — scripts that execute slowly on form load degrade the user experience at scale

Business Process Flows — Guided Stage-Gated Processes¶

Business process flows (BPFs) are Dataverse-native UI constructs that guide users through a defined sequence of stages — each stage containing steps (fields to complete) before the user can advance.

The enterprise use case: BPFs are the right pattern for complex, multi-stage business processes where different data is required at each stage, where stage progression drives business logic (triggering flows, updating status fields), and where visibility of process position matters to the user and their manager.

Common enterprise BPF patterns: sales opportunity progression, customer onboarding, case escalation, approval and review workflows with structured stages.

Business process flows as a logic trigger: BPF stage transitions fire events that Power Automate flows can listen to — enabling stage-driven automation. When an opportunity moves to the Proposal stage, automatically generate a proposal document. When a case moves to Escalated, automatically notify the escalation team. This combination of guided UI (BPF) and automated process (flow) is a powerful enterprise pattern.

Business process flows bridge Logic and Experience — see E — Experience for the UI design considerations.

Third-Party Rule Engines¶

For the majority of enterprise Power Platform solutions, native Dataverse logic — business rules, calculated columns, low-code plugins, and classic plugins — covers all requirements. There is a class of scenario, however, where purpose-built rule engines provide capabilities that native tooling cannot match cleanly.

When to consider a third-party rule engine:

Rule volume — solutions with hundreds or thousands of distinct business rules that would be unmanageable as individual business rules or plugin conditions
Rule change frequency — rules that change weekly or monthly, requiring business analysts to modify them without developer involvement or solution deployment cycles
Regulatory rule sets — compliance, tax, insurance underwriting, or financial calculation rules that are defined by external regulation and must be auditable as a distinct artefact
Rule auditability — scenarios where auditors require a human-readable, independently reviewable record of the rules in force at a specific point in time

North52 — Dataverse-native rule engine: North52 is a managed solution that installs directly into Dataverse — it does not require external infrastructure. Business analysts author rules in a dedicated rule authoring environment within the platform. Rules are versioned, testable, and auditable independently of the solutions that invoke them. For organisations that need enterprise rule management without leaving the Power Platform ecosystem, North52 is the strategic choice.

InRule — Enterprise decision management: InRule is a standalone enterprise decision management platform that integrates with Power Platform via connector or API. It is appropriate for organisations that need a single rule engine governing decisions across multiple platforms — not just Power Platform — and where the rule management discipline needs to be platform-agnostic.

The architectural principle: Third-party rule engines are not a replacement for well-designed native logic — they are a complement for specific high-complexity scenarios. Evaluate them when the volume, change frequency, or auditability requirements of your rule set exceed what native tooling can manage with acceptable overhead.

AI-Augmented Logic¶

The boundary between Logic and AI is not fixed. As AI capabilities mature within Power Platform, a growing class of logic decisions that were previously deterministic are now better served by AI inference.

AI Builder models in flow logic: AI Builder prediction models, classification models, and document processing models can be embedded directly in Power Automate flows as logic steps. The model's output — a prediction score, a classification, an extracted value — becomes an input to the flow's conditional logic. A flow that routes a support case based on AI-predicted urgency, or that approves a document based on AI-extracted compliance fields, combines deterministic orchestration with probabilistic intelligence.

The human-in-the-loop design principle: When AI inference drives a consequential decision within a flow — approval, routing, rejection — design an explicit human review step for cases where the AI confidence score falls below a defined threshold. Flows that act autonomously on low-confidence AI outputs create errors that are difficult to detect and expensive to remediate.

Copilot Studio actions as logic triggers: Copilot Studio agents can invoke Power Automate flows as actions — meaning agent interactions can trigger business processes. A user asking an agent to "create a new customer onboarding request" triggers a flow that creates Dataverse records, initiates an approval, and sends notifications — all from a natural language instruction. This is the logic layer responding to agent-driven intent rather than form submission or record event.

Maturity Levels¶

Level	Description	Suitable For
Basic	Logic lives primarily in apps and flows. Business rules used for simple field validation. No shared logic components.	Personal productivity and simple departmental solutions with limited complexity and change
Intermediate	Logic deliberately placed — server-side rules in Dataverse, reusable flows, some Custom APIs for shared logic. Flows have error handling. Logic is in solutions.	Team and departmental enterprise solutions with moderate complexity and defined ownership
Advanced	Logic fully centralised — Custom APIs for reusable business logic, low-code plugins for server-side enforcement, classic plugins where required, third-party rule engine for high-volume rule sets, all logic version-controlled, testable, and deployable via pipeline.	Mission-critical enterprise solutions with complex business rules, multiple consuming applications, and formal change governance

Safe Zone¶

Solutions using declarative business rules, calculated columns, and simple Power Automate flows for non-critical processes can operate at Basic maturity without significant governance overhead.

Any solution that meets one or more of the following must reach Intermediate or Advanced maturity before Go-Live: - Contains logic that enforces data integrity or compliance requirements - Has multiple apps or flows sharing the same business rules - Processes financial, regulated, or personally identifiable data through logic decisions - Has logic that triggers consequential actions — financial transactions, external notifications, record deletions - Is mission-critical — logic failure has material business impact - Has logic authored by multiple developers across a team

Common Mistakes¶

Logic in the wrong layer — business rules that belong in Dataverse living only in a canvas app formula, bypassed by every other entry point. The rule only fires when the user uses that specific app.
Duplicated logic — the same calculation in three canvas apps, two flows, and a plugin. When the business rule changes, it changes in one place and breaks in the others.
Flows that contain logic instead of calling it — five-hundred-step flows with complex nested conditions that belong in a Custom API or low-code plugin. Untestable, unmaintainable, and impossible to reuse.
No error handling in flows — flows that fail silently when a logic step errors. The process stops; nobody knows; data is incomplete.
Classic plugins for scenarios that low-code plugins now cover — reaching for C# plugin development for logic that Power Fx can now express server-side, adding unnecessary pro-code overhead.
Client SDK scripts enforcing business rules — critical validation logic in JavaScript that a user can bypass by calling the API directly. Client scripts are for UI behaviour; server-side logic is for business integrity.
Business process flows without flow automation — BPFs designed as UI guides with no automation behind stage transitions. The user advances the stage; nothing happens automatically. The process value is unrealised.
No logic ownership — flows and plugins created by individuals who have since left the organisation, with no documented owner. When logic breaks, nobody knows what it was supposed to do.
Automating before understanding — building flows against a process that has never been analysed. Process mining exists precisely to prevent organisations from embedding inefficiency into automation.
Skipping third-party rule engines when they are the right answer — managing hundreds of business rules as individual Dataverse business rules or plugin conditions when a purpose-built rule engine would be dramatically more maintainable.

Readiness Checklist¶

Logic Design - [ ] Logic placement decisions documented — every piece of logic assigned to the correct layer - [ ] Shared logic identified and centralised — no duplication across apps and flows - [ ] Logic ownership assigned — every flow, plugin, and Custom API has a named owner - [ ] Third-party rule engine evaluated for high-volume or high-change-frequency rule sets

Dataverse Logic - [ ] Business rules implemented for all field-level validation that must apply universally - [ ] Business rule scope set to server for integrity-critical rules — not client-only - [ ] Calculated and rollup columns used in preference to flow-maintained fields where appropriate - [ ] Low-code plugins evaluated before classic plugins for server-side logic requirements - [ ] Classic plugins version-controlled, tested, and deployed via solution pipeline

Power Automate - [ ] Flow type selected correctly — automated, instant, or scheduled - [ ] Flows kept thin — logic delegated to Custom APIs or plugins, not embedded in flow steps - [ ] Error handling implemented — try/catch scopes, failure notifications, dead letter logging - [ ] Approval timeout behaviour defined — no approvals that can wait indefinitely - [ ] Approval history stored in Dataverse — not reliant on flow run history retention - [ ] Desktop flows documented as technical debt with API integration roadmap

Power Fx - [ ] Named formulas and variables used — no deeply nested inline expressions - [ ] Delegation compliance verified for all canvas app data queries - [ ] App logic reviewed — business rules moved to Dataverse where appropriate

Client SDK - [ ] Scripts version-controlled and included in solutions - [ ] No business integrity logic in client scripts — server-side enforcement verified - [ ] Script performance tested on form load

Business Process Flows - [ ] Stage transitions wired to Power Automate flows where automation is required - [ ] BPF stages aligned to actual process stages — not UI convenience

AI-Augmented Logic - [ ] Human-in-the-loop defined for all AI-driven consequential decisions - [ ] AI confidence thresholds configured — low-confidence outputs routed to human review - [ ] AI model invocations governed per SHIELD data classification requirements

Part of the DIALOGE Framework — powerplatform.wiki Last updated: March 2026 Last reviewed: March 2026