Enforcing a Required Field by Sales Stage in Dynamics 365 Without Custom Code

Why can a business rule not make a field required at a certain stage?

Because business rule conditions read columns on the row, and the active stage of a business process flow is not a dependable column on the opportunity. Since business process flows became their own tables, the active stage lives on the process instance record, such as the Opportunity Sales Process row linked to the opportunity, not on the opportunity itself. The older stage and process columns on the opportunity are deprecated and are not a reliable signal, especially when a record has switched processes or the flow branches.

So a rule that says "if stage equals Propose, set Budget Amount to business required" has nothing trustworthy to test. It may appear to work in a quick test and then behave inconsistently for records created by another process, imported records or records that moved stage without the form reloading.

That does not make business rules the wrong tool in general. For requirement levels that depend on another field on the same row, they are exactly right, and our guide on what a maker can build without a developer explains where business rules and business process flows fit in a do-it-yourself rollout. For a stage-dependent requirement, start with the business process flow itself.

How do you make a field required at a stage with a business process flow data step?

Edit the flow, not the form. A data step marked Required is part of the stage definition, it is solution aware, and it needs no script. Do this in a development environment and move it through a managed solution, because the flow is usually shared by every seller.

• Open your unmanaged solution in make.powerapps.com, open the business process flow the opportunities use, for example Opportunity Sales Process, and it opens in the process designer.
• Select the stage at which the field must be filled, such as Propose, and add a Data Step from the components pane if the field is not already there.
• Choose the opportunity column in the data step properties, tick Required, and apply the change.
• Validate, save and activate the flow. Changes to an active flow take effect for users once it is saved and activated again.
• Check that the column is available to every security role that uses the flow, and that users have access to the flow itself, or the step will block people who cannot fill it.
• Test with a real seller account on the web app and on the mobile app: try to select Next Stage with the field empty and confirm the stage bar refuses and highlights the step.

Where does a required business process flow step enforce the rule, and where can users bypass it?

A required step guards the act of moving the stage forward in a model-driven app. It does not make the column required on the table, and it does not run when the record changes by any other route. That boundary is the reason most stage rules leak.

When does a business rule based on a stage column work, and when does it fail?

It works when the column it reads is kept in step with the stage by something reliable, and it fails whenever that column lags behind. Some teams add their own choice column, such as Sales Stage, set by a real-time workflow when the active stage on the process table changes, and then write a business rule: if Sales Stage equals Propose, set Budget Amount to business required. Others read the Pipeline Phase column that the standard sales process maintains.

This gives a visible required marker on the form, which a data step does not, and it can drive other form behaviour such as showing a section. Its limits are worth knowing before you rely on it for an audit.

• The rule evaluates when the form loads and when a condition column changes on the form. If the stage column is updated on the server after a save, the form may not reflect it until it is refreshed.
• Set business required only affects forms. Even with the rule scoped to the table, the required action does not stop a save through the API or an import, so it is a guide for users rather than enforcement. Check current Microsoft documentation for which actions run server side.
• Pipeline Phase and similar columns are tied to a specific process. Records on a custom or branched flow may not populate them the way you expect, so test each flow separately.
• A business required marker blocks saving the form, not moving the stage, so it can stop a user saving unrelated edits on a record that is already past the stage. Many teams find the data step alone is the less frustrating choice.

What does form script with setRequiredLevel add to a stage rule?

Form script is code, so it is optional for anyone following the no-code route, but it fills two gaps a data step leaves. It reads the real active stage from the flow on the form, and it can react before the stage moves.

A small JavaScript web resource registered on the opportunity form's OnLoad event can call formContext.data.process.getActiveStage() and compare the stage name or identifier, then call formContext.getAttribute("budgetamount").setRequiredLevel("required") so the column shows the required marker at the right stage and "none" at the others. Registering formContext.data.process.addOnStageChange keeps that marker correct as the user moves back and forth, and addOnPreStageChange lets the script inspect a condition a data step cannot express, such as "Budget Amount is required at Propose only when the deal type is New Business", and cancel the move with the event arguments' preventDefault method and a clear form notification.

Compare stages by identifier rather than display name where you can, because names get translated and renamed. Keep the script in a solution, and remember it still only runs on the form: the API and imports never execute it. Check the current Client API reference before building, since process methods have changed across releases.

How do you enforce the rule when records change through the API, imports or integrations?

Put the rule where every write passes through: the server. Without writing code, a classic real-time workflow can do this, because business process flow tables such as Opportunity Sales Process can be used as the table a workflow runs on.

Create a real-time workflow on the process table that runs before the Active Stage column changes. Add a condition that checks the new stage and whether the related opportunity's column contains data, and if it does not, use Stop Workflow with the status Canceled and a message such as "Budget Amount is required before moving to Propose". The change is rolled back and the message is returned to whoever attempted it, whether a user, a cloud flow or an integration. Add a second real-time workflow on the opportunity for the status change to Won, so Close as Won cannot bypass the same requirement.

Microsoft steers new background automation towards Power Automate, but cloud flows run after the save and cannot cancel it, so real-time workflows remain the no-code option for synchronous blocking. Check current Microsoft documentation for their status. Where the logic grows complex, a plug-in registered on the pre-operation stage does the same job in code and is easier to test, which is where a developer earns their place. Imports and migrations should also validate data before loading, rather than relying on the rule to reject rows one by one.

Which approach should you use for each stage-dependent required field?

Most organisations need two layers: a required data step for the people using the app, and a server-side rule for everything else. The other options add polish or handle conditions the data step cannot express.

Why do users type rubbish into required fields, and what actually prevents it?

Because a required field only proves that something was typed. When a seller is forced to fill a column they cannot answer yet, they type a full stop, "tbc" or "n/a", and the record now looks compliant while holding nothing. Making more fields required usually makes the data worse, not better.

The fixes are about design, not enforcement. Our sales process redesign guide covers cutting mandatory fields across the whole process; for a single stage rule, these are the countermeasures that work.

• Ask for the field at the stage where the seller can genuinely know it, which is the whole point of a stage rule, rather than at creation.
• Replace free text with a choice column, a lookup or a number wherever possible, so there is no box to type "tbc" into. Add an explicit "Not yet known" option only if the process allows it, and report on it.
• Validate the shape of the value: a business rule with Show Error Message can reject an amount of zero, a close date in the past or an end date before a start date.
• Set a minimum meaningful answer for unavoidable text fields, and use a view that finds placeholder values such as single characters, "tbc", "test" and "n/a" so they are visible.
• Make the field matter: use it in the pipeline review, the forecast or the approval, so managers notice empty or meaningless answers and ask about them.
• Turn on auditing for the columns an auditor will ask about, so changes and who made them can be shown later.

How do you fix opportunities that already skipped the rule before an audit?

Adding the rule protects future stage changes only. Records already past the stage with the field empty stay as they are, and they are what an auditor will sample.

Build an Advanced Find or model-driven view of open opportunities whose active stage is at or beyond the required stage and whose column is empty or holds a placeholder value, and share it with the owning managers. Agree whether each record is corrected by its owner, moved back a stage or closed. Do not bulk fill the column with a default value to make the view empty, because that manufactures exactly the rubbish the rule was meant to prevent. Keep the view as a standing control after the audit, and if it keeps filling up, look for the bypass route in the table above. If the gaps point to a wider build problem, our Dynamics 365 health check is the right starting point.

Should stage-dependent data rules live in Dynamics 365 or a custom CRM?

For organisations already on Dynamics 365 Sales, the answer is to use the platform: required data steps, a server-side rule and a well-designed set of fields cover this without custom development, and what a full Dynamics 365 Sales implementation includes is on our service page.

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. If the real problem is that a licensed CRM is more than the sales team needs, stage gates, required evidence and server-side validation are equally natural in a custom-built CRM on React, Node.js, PostgreSQL or .NET, where the rule is simply part of the application.

How does Solzet help enforce required fields by sales stage in Dynamics 365?

We start with the rule and the routes: which fields must be present at which stage, and every way an opportunity actually changes stage or closes in your environment, including integrations, flows, imports and the close dialog. Then we add the required data steps, the server-side rule for the bypass routes, any form script the conditions genuinely need, and the view that finds records already out of line, all in a solution moved through your environments. When an audit is close, we do this as a short, contained piece of work and hand the controls over documented.

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 sales process fixes sit with our Dynamics 365 Sales service, and if you are deciding whether to do this in house, our consultant or do-it-yourself guide sets out the trade-offs.