Dataverse Business Rules That Do Not Fire in Canvas Apps

Why are Dataverse business rules not working in a canvas app?

Because most business rules were never designed to run there. Business rules are built in the table designer, which makes them look like a property of the table, but each rule has a scope, and rules created while working on a form are often scoped to that form or to all forms. A canvas app does not load model-driven forms, so every rule scoped to a form, or to all forms, simply does not exist from the canvas app's point of view. The app saves whatever its controls send, and Dataverse accepts it.

The result is usually discovered late: records created in the canvas app with a required-looking field empty, a discount above the limit the form would have blocked, or values in fields the form hides for that record type. Nothing errored, because nothing was checking. Custom pages in model-driven apps are canvas technology too, so they behave the same way.

• Records from the canvas app are missing values that model-driven users can never leave empty.
• Values the form would clear or recalculate are left as the user typed them.
• Fields hidden on the form for a record type contain data for that type.
• Error messages that stop model-driven users never appear in the app.
• Imports, flows and integrations show the same gaps as the canvas app.

Which business rule scopes run where?

Scope is set in the business rule designer and decides everything. Check it on every rule before assuming anything about enforcement.

Which business rule actions actually take effect on the server?

Only the actions that change or validate data. A server has no form, so there is nothing to hide, lock or mark with a red asterisk. Actions that set or clear a field's value, and a Show error message action that rejects the save, are the ones that matter for data quality at Entity scope. Actions that set visibility, enable or lock a field, set the requirement level or show a recommendation affect the model-driven form only, and a rule built mainly from them protects nothing when data arrives another way. Treat default values with care as well, and test whether a default is applied on create from each client you use.

This is the part most makers get wrong, because the same rule looks complete in the designer. Microsoft adjusts the designer and its documentation over time, so check the current documentation for the action list and, more importantly, test every critical rule by creating and updating rows from a canvas app or the Web API and confirming the result.

Why do hidden fields end up full of invalid data?

Because a show or hide rule quietly encodes a data rule that nobody wrote down. When a form hides a "Competitor details" field unless the loss reason is "Lost to competitor", the real rule is that the field should be empty for every other reason. The form enforces that only by making the field unreachable, and even then a value entered before the reason changed stays in the hidden field.

A canvas app has its own layout, so the maker may show the field for every record, or a user changes the reason after filling it in. Both paths write data the model-driven form would never let anyone create. Rewrite each visibility rule as an explicit data rule at the right layer: clear the dependent field on the server when the condition no longer holds, or reject the save with a clear message, and let visibility remain a presentation choice on each interface.

How do you enforce critical rules for every client?

Move them to the server, where every client passes. Decide per rule how much it matters: a rule that protects finance, compliance or integration data must hold however the row arrives, while a rule that helps users fill a form faster can stay in the interface.

For simple conditions, an Entity scope business rule with Set field value or Show error message is the lightest server-side option and remains maintainable by makers. For anything that needs related records, several steps, calculations across rows, or reliable error text for integrations, use a synchronous plug-in registered on create and update in the pre-operation stage, which can inspect the incoming values and throw an error that cancels the save. Keep those plug-ins fast and narrowly filtered on the columns they check; the design mistakes to avoid are covered in common Dynamics 365 customization mistakes, and tracing plug-in failures is covered in plug-in logging and diagnostics.

• Entity scope business rule: simple conditions on the same row, set, clear or reject.
• Synchronous pre-operation plug-in: related data, complex conditions, cross-row checks and messages that integrations must be able to rely on.
• Column requirement level: still useful for model-driven forms and as metadata for canvas cards, but not as enforcement.
• Asynchronous flows: good for notification and repair, never for enforcement, because the invalid row has already been saved.

How do you replicate the validation in a canvas app with Power Fx?

Repeat the user-facing part so people get feedback before they press save, and keep the server rule as the guarantee. A canvas app user who only discovers a rule through a server error after filling in a whole screen will stop trusting the app.

• Set each card's Required property from the rule, including conditional requirements, rather than relying only on the column requirement level that edit forms read by default.
• Use the Visible and DisplayMode properties to mirror the model-driven layout where it helps, but never as the only protection.
• Disable the save button until the conditions are met, and show the reason next to the field instead of only in a banner.
• Clear dependent values in the app when the condition changes, the same way the server rule does.
• Handle server rejections: wrap Patch or SubmitForm with IfError or check Errors on the data source, and show the message the business rule or plug-in returned.
• Put shared conditions in named formulas or a component so several screens use one definition.

How do you find the invalid rows that are already written?

Turn each broken rule into a query that finds its violations, then fix them deliberately. For every rule, write the opposite condition as a Dataverse view or FetchXML query: rows where the required field is empty, rows where the hidden field has a value for the wrong type, rows where the amount exceeds the limit. Advanced find in a model-driven app is enough to build and save most of these, and the saved views become the remediation list.

Check when and where each bad row came from before correcting it, using created by, modified on and auditing where it is enabled, because some rows may have been valid at the time or entered by an integration that needs fixing too. Correct small sets by hand or with bulk edit; for larger sets use a flow or a script that records every change. Where the canvas app loads these rows, remember that its queries have delegation limits, so do not check data quality with a gallery filter; the limits are explained in fixing slow canvas app galleries with delegation.

• One saved view or FetchXML query per rule, named with the rule's catalogue ID.
• Count violations before and after the fix, and keep the view as an ongoing check.
• Deploy the server-side rule before cleaning up, or new invalid rows keep arriving during remediation.
• Schedule a flow to report new violations to the data owner, so gaps in enforcement show up quickly.

How do you keep rules in sync across many forms and apps?

Give every rule one identity and record everywhere it is implemented. Without that, the same rule ends up in a form business rule, two canvas apps and a plug-in, each slightly different, and nobody knows which one is right. A rules catalogue can be a simple table in Dataverse or a document under version control; what matters is that it is the first place anyone looks before changing a rule.

How do you test that a rule really holds from every entry point?

Test through the doors data actually uses, not only the model-driven form. For each critical rule, try to write an invalid row from a canvas app, through the Web API or a flow, and through whatever import or integration feeds the table, and confirm that the save is rejected or corrected with the expected message. Then check the violation query returns nothing new.

Run these tests as a user with the production security role, keep them in the catalogue, and repeat them when rules, apps or plug-ins change, and after release waves. A rule that passes in the model-driven form and was never tried from the canvas app is exactly how this problem started.

Should business-critical validation live in Dataverse or a custom-built CRM?

For organisations on Dynamics 365 Customer Engagement or Power Platform, Dataverse has the right tools: Entity scope rules and plug-ins enforce data centrally for every app, and canvas and model-driven apps can share one data model safely once the rules are in the right layer. The problem is placement, not the platform.

We recommend the right solution - whether that's Microsoft Dynamics 365, Power Platform, or a custom-built CRM. Some businesses need the Microsoft ecosystem. Others need full control without licensing. We deliver both. Where an organisation would rather own validation entirely in application code, without Microsoft licensing, a custom-built CRM on React, Node.js, PostgreSQL or .NET puts rules in one server-side domain layer, with the same principle: enforce on the server, repeat in the interface for usability.

How does Solzet help when business rules do not protect data from canvas apps?

We start by inventorying every business rule, its scope and actions, the plug-ins on the same tables and each canvas app writing to them, and by running violation queries so the size of the data problem is known. Then we move critical rules to Entity scope or synchronous plug-ins, add the matching Power Fx validation and error handling to the apps, clean the invalid rows with a recorded, reversible approach, and leave a rules catalogue with tests for each entry point.

The work is done by senior consultants and full-stack developers delivering remotely from Yerevan, Armenia, with 8+ years of Dynamics 365 Customer Engagement and Power Platform work, directly for your team or white-label for Microsoft partners. Wider app and platform work sits with our Power Platform consulting service, and rules that must hold for an audit are covered in closing a Dynamics forms compliance gap.