Approving a Delivery Date in Business Central: Two Gates Before You Promise

In a make-to-order business, the delivery date is the one promise that nobody formally approves. Business Central can turn it into an approval, but not with the default logic: standard approvals route on who asked and how much the document is worth, while a date needs two checks in a fixed order. First, can we make this part? Then, do we have the material and the machine hours? Only after both should a date go back to the customer.

The requirement came out of a scoping site visit at a make-to-order manufacturer. The customer sends drawings, a quantity and a wished date. When nothing technical is in question, the date can be confirmed directly. Otherwise, engineering validates first, then procurement and machine time. And one sentence from that visit carries the whole design: the manufacturer wanted the first validation to be automatic, unless something is off.

Why does a delivery date need an approval at all?

Because in make-to-order work the date is usually set before anyone has checked it. Sales enters a date to keep the customer happy. Engineering discovers a week later that the part needs a new routing. Planning discovers after that that the machine is booked. By then the customer has a date in writing.

Business Central already separates the two ideas you need. The sales line carries a Requested Delivery Date, which is the date the customer asked for, and a Promised Delivery Date, which is what you commit to. Treat them as different kinds of information: the request is data you record, the promise is a decision someone takes. An approval workflow is simply the thing that stands between the two.

When the promised date is typed in the same minute as the requested date, the difference collapses, and so does every later conversation about who promised what.

What does Business Central already give you for delivery dates?

Order promising, and it is useful, but it answers a different question. From a sales order, the Order Promising Lines page offers two calculations. Available to Promise checks unreserved quantities in inventory and on planned receipts. Capable to Promise runs a “what if” for the quantity you don’t have, and calculates the earliest date the item could be available if it is produced, purchased or transferred.

Three details matter in practice:

• An item is only included in the order promising calculation if it is marked Critical on its item card.
• Accepting a Capable to Promise date creates a planning line and a reservation entry, so it is not a harmless simulation.
• Manufacturing itself (production BOMs, routings, work and machine centers) requires the Premium experience.

What order promising does not do is ask anyone. It calculates from availability and lead times; it cannot know that engineering hasn’t looked at the drawing yet. So use its output as the input to the second gate, not as the promise.

What does the standard approval workflow do, and where does it stop?

Business Central ships approval workflows for sales documents, and they are more capable than most teams realize.

On the Workflow User Groups page, each member gets a Sequence No., which sets the order of approval. With sequential approval, a request that the first approver doesn’t approve never reaches the next one. That is exactly the behavior a two-gate date check needs. Workflow user groups add one rule worth knowing: if several users in the group share the last sequence number, all of them must approve. Put procurement and production planning together on that last number, after engineering, and the second gate needs both signatures: neither can confirm a date alone.

The approval response also carries a Due Date Formula, the number of days the approver has to act, and a Delegate After option that hands the request to a substitute after one, two or five days. On a delivery date, those two settings are not administrative details. A request that sits unanswered is a customer who hasn’t had a date.

Where the standard stops is the trigger. Approval user setup routes by approver hierarchy and amount, with a Sales Amount Approval Limit per approver. Amount is the wrong measure for a date. A small order for a part you have never made is exactly the one that needs engineering, and an amount limit waves it straight through. The question being approved is “can we make this by then”, and the order total says nothing about it.

Why must engineering validate before procurement and planning?

Because the second answer depends on the first. Procurement can only check material once the material is known, and planning can only check machine time once the routing is known. Both are outputs of the engineering review. Running engineering in parallel with the second gate means your scarcest people check capacity for a part that may be redesigned an hour later.

The order also decides what a rejection means. If engineering says no, the request stops there, and nobody downstream spends time on it. If both gates run at once, a rejection from engineering arrives after planning has already booked the machine, and someone has to unbook it.

This is not a Business Central rule. It is a sequencing decision you make before configuring anything, and it is the part most teams skip when they copy a purchase approval template and rename it.

How do you make the first gate automatic without making it meaningless?

By writing down what “something is off” means, as data, before anyone builds the workflow. An automatic gate whose default is yes is the only kind people don’t route around; a gate that stops every order gets bypassed by the second week.

Here is the kind of rule we would propose to decide that an order skips engineering review:

• The item has already been produced, and its production BOM and routing haven’t changed since.
• The quantity is inside the range already made for that item.
• The requested date leaves at least the item’s lead time.

Each one is a fact the system holds, not an opinion. Anything that fails a rule goes to engineering; everything else goes straight to the second gate.

Some of these rules fit into workflow event conditions, which filter on field values. Others, like “has this item ever been produced”, need a query a condition can’t express. When the event or the check you need isn’t in your workflow library, it is added by extension: Microsoft documents subscribing to OnAddWorkflowEventsToLibrary and OnAddWorkflowResponsesToLibrary for exactly this. The same documentation carries a warning to respect: during an upgrade, the libraries of workflow events, responses and table relations are removed and recreated, and custom records added through those extension points are the ones that get recreated.

One trap sits in the approval setup itself. When the same user is both the requester and an approver in a workflow user group, their own requests are always approved automatically. If the engineer who sets up a new part is also the one who raises the date request, the engineering gate passes without anyone having looked. Keep requesters out of the group that approves them.

Standard configuration or extension: which one should you build?

Start with the standard. A sales approval workflow with one workflow user group, engineering on sequence 1 and procurement and planning sharing sequence 2, gives you a real two-gate check without a line of code. Run it for a few months and count one thing: how many requests engineering approved without changing anything. That number tells you whether an automatic rule is worth building. We make the same argument about which Business Central customizations should never be written: a requirement is not a reason to code until you know what it costs to leave it in configuration.

An extension earns its place in two situations. The first is when the date must be approved on its own, separately from the order, for example when a released order’s date changes. Business Central can already hold a changed field value until it is approved, keeping the old value in place, as it does for fields like a customer’s credit limit. Applying that to a delivery date means the right event must exist for that record. The second is when the automatic rule needs data a condition can’t read. In both cases it is a small, well-bounded piece of Business Central development, not a rebuild of the sales process.

The Asio Services way

A delivery date that keeps slipping is rarely a workflow problem. It is usually the visible end of something upstream: engineering finding out late, capacity data nobody trusts, a sales team rewarded for saying yes. A root cause analysis of the ERP project is where that gets separated from the tooling question.

What we do before configuring any approval is write three things on one page: the gates and their order, the rule that lets an order skip the first gate, and who may never approve their own request. If that page can’t be written, the workflow will only automate the confusion. If you want to see whether your own date promise holds up, the Clarity Form is where we start.

FAQ

Can Business Central approve a delivery date without custom code?

Yes, through a standard sales approval workflow with a workflow user group whose sequence numbers put engineering first and procurement and planning second. What the standard can’t do on its own is approve the date separately from the order, or skip a gate based on a rule a field condition can’t express.

What is the difference between Requested and Promised Delivery Date?

The Requested Delivery Date is what the customer asked for. The Promised Delivery Date is what you commit to. Keeping them apart, with an approval between the two, is what makes it possible to know later who promised what.

Does Capable to Promise replace the approval?

No. Capable to Promise calculates the earliest date the item could be available from availability and lead times, and accepting it creates a planning line and a reservation entry. It doesn’t know whether engineering has validated the part, so it is an input to the approval, not a substitute for it.

Why can a user’s own date request pass engineering review automatically?

Business Central automatically approves requests from a user who is also an approver in the same workflow user group. If the person raising the request sits in the engineering group, the engineering gate is passed without review, so requesters should be kept out of the group that approves them.