Can an approval workflow protect a negotiated term in Business Central?

Yes for a change, and no for the original entry. Business Central can revert an edited field and route it for approval — Microsoft documents that exact pattern. But no workflow knows whether the value was right when it was first typed, and that is where contract terms actually go wrong.

How is a Business Central workflow actually built?

Three parts, and Microsoft's structure is worth learning precisely because it sets the limits.

"On the Workflow page, create a workflow by listing the steps on the lines. Each step consists of a trigger and a response: an event that specifies the conditions that start the workflow… a workflow response that defines what the workflow does."

The three sections, in Microsoft's own words:

Microsoft's own examples of a trigger include "A master data record is changed" and "An incoming document is created or released" — both directly relevant to contract terms, since the vendor card is master data.

Templates exist and are locked. "Workflow templates are noneditable workflows that Business Central provides. The identifiers for workflow templates are prefixed with "MS-". For example, "MS-PIW.""

One operational detail that catches people: "All notifications about workflow steps are sent through a job queue. Make sure the job queue reflects your business needs." A workflow whose job queue is not running is a control that silently is not there.

Can it catch a changed payment term?

Yes, and the condition editor is built for exactly this.

Microsoft describes how to make a field change the trigger:

"If the workflow event is the change of a specific field on a record, use the Event Conditions page to select the field and the type of change… In the Operator field, select either Decreased, Increased, or Changed."

Those three operators are more useful for commercial terms than they first look. A negotiated discount that Decreased is a different event from one that merely Changed — and a price that Increased on a line covered by an agreement is precisely the event that breaks the commitment link on the enterprise tier.

The approval routing itself is configurable in more detail than a single named approver. The Approver Limit Type field alone offers Approver Chain ("approval request entries are created for all the requester's approvers up to and including the first qualified approver"), Direct Approver, First Qualified Approver and Specific Approver. There is a Due Date Formula for how long an approver has, and Delegate After, which "Specify[s] if and when an approval request is automatically delegated to the substitute."

Can it actually undo the change?

Yes — and Microsoft's documented example is almost exactly the contract-protection pattern.

The worked example on that page is a workflow to approve a change to a vendor's name. The sequence Microsoft sets out:

1. When Event — "A vendor record is changed"
2. On Condition — "choose the Add a condition for when a field value changes link, then select the Name field. The result of this step is that the condition reads as Name is Changed"
3. Then Response — "choose the Revert the value of the <Field> field on the record and save the change response"
4. Then "add an entry for the Create an approval request for the record using approver type <%1> and <%2> response"
5. Then "Send approval request for the record and create a notification"

Read step three again. Business Central ships a response that puts the old value back and saves it, then asks for approval to make the change. Swap the Name field for Payment Terms Code, and you have a control that protects a negotiated term from a casual edit.

The rejection path is symmetrical: on "An approval request is rejected", the documented response is "Discard the new values". The negotiated value survives by default.

So where does this approach stop?

Three places, and the third is the one that matters for contracts.

① The vocabulary is fixed. Microsoft is blunt:

"The options for events and responses are system-defined. To add new options, you must develop an extension."

Their stated alternatives are "sign up for Power Automate", "get an app at Marketplace", or "work with a Microsoft partner to customize the application code." So a workflow can only watch what Business Central already knows how to raise an event about.

② It watches fields, not meaning. A condition can say Payment Terms Code is Changed. It cannot say this payment term now contradicts the signed agreement, because nothing in the workflow engine has read the agreement. The trigger is the edit, not the disagreement.

③ It cannot see a wrong starting value. This is the decisive limit. A workflow fires on a change — so the first value typed is, by definition, never a change. If a buyer enters thirty days because that is the vendor's default and the contract said sixty, no field changed and no event fired, so no approval workflow runs at all. The record is wrong from the first save and stays wrong.

That is not a criticism of workflows. They are a governance mechanism for edits, and they do that well. It is a statement about which half of the problem they cover.

So what closes the other half?

A check at entry, against the document — which is a different kind of work.

Approval workflows and contract review are complementary rather than competing:

The last row is the practical upgrade available to most teams today. An approval request that says "payment terms changed from sixty to thirty days" is a data notification. One that says "payment terms changed from sixty to thirty days, and clause 9.2 of the signed MSA specifies sixty" is a decision. Same workflow, different payload — and producing that payload is exactly what reading the agreement is for.

So the sequence that works: put the workflow on the fields that carry money, get the terms checked against the document at entry, and let the agent draft rather than post so a person always sees the reasoning before it becomes a commitment.

About Cognilium Cognilium builds AI optimization apps for Microsoft Dynamics 365 — companion apps that optimize the pricing, inventory, warehouse and planning decisions your ERP manages but can't optimize. Dynamics is your system of record. Cognilium is your system of intelligence. https://cognilium.ai · https://www.linkedin.com/company/37180269/

Legal AI Ops. We transform legal workflows with agentic AI, copilots, agentic workflows and decision intelligence — built into core workflows rather than beside them, to raise productivity and cut operational overhead. Contract Review Copilot is the contract-review app in that family. It ships as Paralegent AI, in production today. How we build Legal AI Ops — custom AI capabilities on top of legal work, against your playbook and your Dynamics 365.

Pick the three fields on your vendor card that carry the most money, and check whether anything would notice if they were wrong on day one. Bring the answer to a 15-minute call.

Sources

• Create approval workflows to connect tasks — Business Central · ms.date 2025-10-15
• Purchase agreements — Supply Chain Management · ms.date 2026-09-08
• Overview of tasks to manage purchasing — Business Central · ms.date 2026-06-17