Compliance Rules Missing From Dynamics 365 Forms With Eight Weeks to Audit

Why does a rule enforced only on the form fail an audit?

Because the form is one of several ways a record reaches Dataverse, and the auditor knows it. Users create records in the model-driven form, but records also arrive through the Web API and SDK, Excel and data imports, dataflows, Power Automate flows, integrations, other apps built on the same tables, and bulk edits. Logic attached to the form only runs when the form is used.

So a control that says "a case cannot be created without a linked customer contract" is not a control if it exists only as a form business rule or a required field on the form. A tester creates the record through the API or an import file, it saves, and the finding writes itself. The question to answer before the audit is not whether the form behaves, but whether the rule holds for every write channel, and whether you can prove from what date it did. This page is technical guidance for that question, not legal or regulatory advice; what the rule must be comes from your compliance function.

Which Dataverse mechanisms enforce a rule on every write channel?

The mechanisms differ in where they run, not in how they look to a user on the form. Microsoft revises some of this behaviour, so confirm the details against current documentation and, more importantly, prove each control with a test through the API before you rely on it.

How do you prevent a Dataverse record being created without a required lookup?

This is a frequent version of the problem: a record must always be linked to a parent, such as a case to a contract or an application to a customer. Here is how the three usual options compare for that specific rule.

• On Create, check that the lookup column is present in the Target and is not null. On Update, only act when the Target contains the column, and reject a null value; there is no need to retrieve the record unless the rule depends on other columns.
• PreValidation runs before most platform checks and, for a top-level call, outside the database transaction, so it rejects early. PreOperation runs inside the transaction. Either works for a simple required-lookup check; use PreOperation where the check depends on values set by other logic earlier in the pipeline.
• Test the bulk path as well. Imports and integrations may use CreateMultiple, UpdateMultiple or ExecuteMultiple, so prove the plug-in fires and rejects in those cases in your environment, and check current Microsoft guidance on registering for the bulk messages.
• Write an error message a user and an integration developer can both act on, naming the rule and the missing column.
• Callers holding the privilege to bypass custom business logic can skip synchronous plug-ins and real-time workflows by request parameter. Review who holds it, including service accounts, and include that review in the evidence.

Can a real-time workflow stop a record being created?

It can make the create fail, which is often what people mean, but it is worth being precise because the difference matters to an auditor and to a developer. For the Create event a real-time workflow can only run after the core operation, not before it. The record has been written inside the database transaction when the workflow runs. If the workflow reaches a Stop workflow step with status Canceled, the platform raises an error with your message and the whole transaction is rolled back, so no record remains and the caller, whether a user on the form or an integration using the API, receives the error. For Update and Delete a real-time workflow can also be set to run before the operation.

That makes a real-time workflow a workable no-code option when there is no developer available and the rule is simple. The limits are real, though: conditions are harder to express and unit test than code, behaviour in bulk and nested operations needs testing, it is a classic workflow when Microsoft recommends plug-ins and Power Automate for new work, and it is more logic in a place future teams must remember to maintain. Where a developer is available, a plug-in is the control we would put in front of an auditor. When no-code configuration stops being enough in general is covered in when to hire a Dynamics 365 consultant or do it yourself.

Which rules will the auditor actually test?

Start the eight weeks with an inventory, not with code. Take the control descriptions, policies and last findings from your compliance team and turn each one into a rule statement against specific tables and columns, then find where, if anywhere, it is enforced today. Most teams discover some rules are enforced only on one form, some only in a flow that runs after save, some in a script that was copied to one form but not another, and some nowhere.

• The rule in one sentence, and the control or policy it comes from.
• Tables, columns and messages it affects: create, update, status change, assign, delete.
• Every write channel that touches those tables: forms, apps, imports, integrations, flows and service accounts.
• Where it is enforced today, and whether that enforcement is UI only, asynchronous or server-side.
• The count of existing records that break it, from a saved view or query.
• The evidence the auditor will expect to see for it, agreed with compliance now rather than in week seven.

What does the eight-week plan look like?

The order matters more than the exact weeks. Server-side enforcement goes first because it is the control; everything visible on the form is guidance layered on top. Customisation that could destabilise the environment before the audit waits.

What should happen to existing records that already break the rule?

Enforcing a rule from today does not make yesterday's records compliant, and an auditor sampling historic records will find them. Decide for each rule, with compliance, what happens to the backlog, and record the decision.

• Report: a saved view or query listing every non-compliant record, with its count on the day enforcement went live.
• Fix: where the missing value can be established from a reliable source, correct the records through a controlled, logged update so the audit history shows who changed them and when. Watch the new plug-in: an update that does not supply the missing lookup will now be rejected, so fix records by setting the value, not by touching unrelated columns.
• Flag: where the value cannot be established, mark the record with a documented exception, a reason and an owner, and exclude it from processes that depend on the rule.
• Never bulk-fill a placeholder parent to make the count go to zero. It hides the gap and creates a worse finding.
• If duplicates are part of the problem, the matching and merge approach is covered in Dynamics 365 duplicate data cleanup.

Why should PCF controls and custom UI wait until after the audit?

Because they do not add control, and they add change. A PCF control or custom page can make the compliant path easier to follow, but it runs in the browser like any other form logic, so it cannot be the enforcement. Built under deadline pressure, it also brings new failure modes into production weeks before an audit: behaviour that differs between the test harness and a real form, performance issues and release-wave surprises, covered in why PCF controls fail in production.

Put the requirement on the server, use the supported out-of-the-box form features to guide users, and schedule the richer interface for after the audit, when it can be designed and tested properly through our PCF controls development work.

What goes into the audit evidence pack?

The pack answers four questions for every rule: what is enforced, from when, how you know it works, and what happened to records that predate it. Audit history retention and exporting who-changed-what evidence from Dataverse are covered in Dynamics 365 audit trails and compliance.

• The rule list: each rule, its source control or policy, the tables and messages it covers.
• How it is enforced: plug-in assembly and step registration (message, table, stage, mode, filtering attributes), exported from the environment, and the managed solution name and version that deployed it.
• From when: the deployment record from your pipeline or release log with date and approver. Solutions moved by hand make this hard to prove, which is one reason to move to Power Platform ALM with PAC CLI and pipelines.
• Test evidence: attempted creates and updates through the form, Web API, import and each integration, showing rejection with the error message, dated and repeatable.
• Dataverse audit history for the affected tables, showing records and changes since enforcement, and the plug-in trace log settings used during testing.
• The existing-record report on the enforcement date, the fixes applied and the exception list with owners.
• Who holds the privilege to bypass custom logic, and why.

Is Dynamics 365 still the right platform for these controls?

Usually yes. Dataverse gives you a transactional plug-in pipeline, auditing and a security model that can carry these controls well once they are in the right layer. A compliance gap found on the form is a design problem, not evidence that the platform is wrong. If the gap turns out to be one symptom of a wider pattern, such as heavy customisation, fragile plug-ins and no ALM, an independent Dynamics 365 health check and technical audit is the right next step, and the common design errors are catalogued in Dynamics 365 customization mistakes and how to fix them.

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 the controls you need, the hosting you must evidence or the licensing model do not fit Microsoft's platform, a custom-built CRM on React, Node.js, PostgreSQL or .NET is the alternative. If the audit needs a whole process built rather than one rule enforced, see building a CRM in 60 days for an audit.

How does Solzet help close a compliance gap before an audit?

We work in the order of this page: the rule inventory with your compliance team, server-side enforcement in plug-ins deployed through managed solutions, the existing-record report and remediation, form alignment, channel testing and the evidence pack, with PCF and interface work scheduled after the audit. Plug-in and Dataverse delivery is part of our Dynamics 365 development service.

Solzet delivers remotely from Yerevan, Armenia, with senior consultants and full-stack developers and 8+ years of Dynamics 365 Customer Engagement and Power Platform work, directly or white-label for Microsoft partners.