Set Up Approval Routing

Build the smallest configuration that actually works, prove it routes, then narrow it. Doing it in that order saves the most common wasted afternoon in this product.

1. Activate routing

Search → DocumentQ Approval Setup → Activate Approval Routing

Afterwards, read Approval Mode on the same page:

  • Full — DocumentQ routes. Continue to step 2.
  • Deferred — an existing approval workflow already owns purchase approval on this tenant, and it is named on the page. Business Central allows only one enabled workflow per document type, so that workflow must be disabled before DocumentQ’s routing can take effect. This is a Business Central constraint, not a DocumentQ one.

2. Turn on the no-match guard

Still on DocumentQ Approval Setup, turn on No-Match Policy Guarded.

Do this before you create anything, not after. Without it, submitting a document that no published rule matches can appear to succeed while nobody has actually been asked to approve anything. With it on, the submission fails with a clear error instead.

You are about to test a configuration that does not exist yet. You want it to fail loudly.

3. Create a route

Search → DocumentQ Approval Routes → New

Give the route a code, then add one level:

  • Approver KindNamed User.
  • Approver — the approver’s exact Business Central user name.

That last field is the single most common mistake in this setup. It is the user name, not the display name and not the email address. Copy it from Users rather than typing what you think it is.

4. Create a rule that matches everything

Search → DocumentQ Approval Rules → New

  • Point the rule at the route you just created.
  • Add no criteria lines. A rule with no criteria matches every document — which is exactly what you want for a first test.
  • Set Lifecycle State to Published.

A rule left at Draft is never evaluated, and nothing warns you about it. If you take one thing from this page, take that.

5. Submit a document and prove it routed

Register a document, then use Business Central’s own Send Approval Request on the resulting purchase invoice.

Now verify, rather than assuming. Open DocumentQ Approval Instances and find your document:

  • A Rule Code and a Route Code are both filled in → it routed. Good.
  • Both blank → nothing routed. Go back to step 4 and check the Lifecycle State first.

Then check the approver’s side: the request should appear in their Requests to Approve.

6. Approve it and post

When the approver approves, the invoice is released and posting becomes possible — DocumentQ’s own posting guard, which runs on every posting attempt, allows it through.

Try the negative case too, once. Reject a test document and then try to post the resulting purchase invoice. It returns to Open but stays unpostable. That looks like a fault the first time you see it; it is the guarantee working.

7. Now narrow it

Only once a rule that matches everything demonstrably routes should you start adding criteria — by vendor, by amount, by exception code, and so on. Add one criterion at a time and re-test, because a rule that matches nothing behaves identically to a rule that does not exist.

Make sure approvers actually hear about it

Both the submitter and the approver need a row in Business Central’s own User Setup with a valid email address.

Without it, routing still works and the request still appears in Requests to Approve — the approver is simply never told. That produces a queue that looks healthy and moves at the speed of somebody happening to look.

Where approval is not optional

For a reconciled, PO-backed invoice, approval is a policy choice — the purchase order and posted receipt are already the control.

For a manually coded non-PO invoice, approval is the control. Those documents cannot be posted without one, and if nothing routed, DocumentQ keeps them blocked and tells you so rather than letting them through. Configure at least one rule that covers them before you start using that path in anger.

Questions about DocumentQ?

Support: support@dynamicspro.ca · 416-843-6575