---
title: "Can an approval workflow protect a negotiated term in Business Central?"
canonical_url: "https://cognilium.ai/blogs/approval-workflow-protect-negotiated-term-business-central"
slug: "approval-workflow-protect-negotiated-term-business-central"
section: "blogs"
date_published: "2026-09-11"
date_modified: "2026-09-11"
word_count: 2041
reading_time_minutes: 9
author: "Mudassir Marwat"
author_identifier: "0009-0008-1927-2598"
person_same_as:
  - "https://www.linkedin.com/in/mudassir-marwat/"
  - "https://orcid.org/0009-0008-1927-2598"
  - "https://github.com/mudassirmarwat"
  - "https://medium.com/@mudassir-marwat"
  - "https://www.youtube.com/@mudassir-marwat"
  - "https://dev.to/mudassirmarwat"
  - "https://hashnode.com/@mudassirmarwat"
  - "https://huggingface.co/mudassirmarwat"
  - "https://bsky.app/profile/mudassir-marwat.bsky.social"
  - "https://substack.com/@mudassirmarwat"
  - "https://topmate.io/mudassirmarwat"
  - "https://fueler.io/mudassirmarwat"
  - "https://www.instagram.com/mudassirmarwat/"
  - "https://www.facebook.com/mudassir.marwat"
  - "https://www.reddit.com/user/mudassirmarwat/"
  - "https://www.f6s.com/member/mudassir-marwat"
  - "https://cognilium.ai/founder"
entities: []
related:
  - "https://cognilium.ai/blogs/ai-contract-review-in-business-central"
  - "https://cognilium.ai/blogs/contracts-in-business-central-vs-finance-supply-chain"
  - "https://cognilium.ai/blogs/what-does-the-payables-agent-read"
---
# Can an approval workflow protect a negotiated term in Business Central?

Yes for a change, no for the original entry. Business Central can revert an edited field and route it, but no workflow knows if the first value was right.

## Key takeaways

- A Business Central workflow is an event, a condition and a response — and the available events and responses are system-defined.
- Business Central ships a revert-and-approve response. Microsoft's own worked example puts an old value back and routes the change for approval.
- A workflow fires on a change, so it can never see a wrong first entry. That is the half of the problem approvals structurally cannot cover.
- Workflows watch fields, not meaning. Nothing in the engine has read the agreement.
- The cheapest real upgrade is the payload, not the routing: an approval request that carries the clause is a decision rather than a notification.

**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](/blogs/contracts-in-business-central-vs-finance-supply-chain).

**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"*
1. **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*"*
1. **Then Response** — *"choose the **Revert the value of the <Field> field on the record and save the change** response"*
1. Then *"add an entry for the **Create an approval request for the record using approver type <%1> and <%2>** response"*
1. 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](/blogs/ai-contract-review-in-business-central), and let [the agent draft rather than post](/blogs/what-does-the-payables-agent-read) 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](/solutions/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](https://learn.microsoft.com/en-us/dynamics365/business-central/across-how-to-create-workflows) · `ms.date` 2025-10-15
- [Purchase agreements — Supply Chain Management](https://learn.microsoft.com/en-us/dynamics365/supply-chain/procurement/purchase-agreements) · `ms.date` 2026-09-08
- [Overview of tasks to manage purchasing — Business Central](https://learn.microsoft.com/en-us/dynamics365/business-central/purchasing-manage-purchasing) · `ms.date` 2026-06-17

## Fact-check

**Tier summary:** 12 × T1 (all verbatim), 3 × T2 — **0 × T4.**

**All three sources fetched before the claims were written.** The `purchase-agreements` page is cited for one cross-tier claim only and was re-fetched today rather than carried over from a sibling article.

**Claim 14 is the article's spine and it is deliberately NOT an absence claim.** We do not say *"Microsoft does not document a way to validate a first entry."* We say a workflow triggers on an event, a change is the event, and a first save is not a change — **which follows from Microsoft's own model rather than from a search that found nothing.** That distinction is why it needs no scope statement.

**Claim 11 is the one place we extend Microsoft's example**, and it is labelled: they document the pattern on the **Name** field, and applying it to **Payment Terms Code** is our suggestion, not their documented scenario.

**No figures of ours.** The only numbers are Microsoft's delegation options, quoted. **No digits in either lifted block.**

**Complement, never compete.** Workflows are described as *"a governance mechanism for edits, and they do that well"*, with the limit framed as which half of the problem they cover. **No vendor or feature is knocked.**

## Frequently asked questions

### How is a Business Central workflow actually built?

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

### Can it catch a changed payment term?

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.

### Can it actually undo the change?

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

### So where does this approach stop?

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

### So what closes the other half?

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

---

Canonical HTML: https://cognilium.ai/blogs/approval-workflow-protect-negotiated-term-business-central