Skip to main content
Cookbook · Business Central

Diagnose a failed Business Central sync

Admin ~5 min

Something didn't show up where you expected. Start in the errors view to see what the connector said, then map that to a known cause.

Before you start​

Do not start by guessing at configuration. Every failure carries a stable error code in square brackets, and that code is the whole diagnosis. [DSBC003] BC server too busy will always be DSBC003, so the code is also searchable across transactions and logs to find every appointment that hit the same problem.

The single most useful distinction, because it decides whether you should do anything at all:

  • Retried codes are picked up automatically by the retry job, which backs off between attempts and leaves the row Failed for the next pass if it runs out. Transient network and throttling failures live here, and they usually clear themselves without you doing anything.
  • Fix configuration codes are not retried. They need a connector or back-office change first, and waiting will not help.

Retrying a fix-configuration error by hand is the most common wasted move.

1. Find the failing transaction​

Open the errors page. It lists every appointment in the faulted state, split across Dynamics, Exchange, and Webhook tabs, so you are only ever looking at one connector family at a time.

Click the magnifying glass to drill in. The detail view shows the appointment, the connectors assigned to it, and every transaction with its status. That last part matters: an appointment can have several connectors, and only one of them may be failing.

2. Read the code​

Take the code from the square brackets and look it up in transaction errors. Each entry pairs what it means with what to do.

The prefix already tells you where to look:

  • DSCFG* is connector configuration. Authentication, URLs, missing fields, Entra ID registration and consent.
  • DSHTTP* is transport. Transient 429s and 5xx responses, proxy tunnel failures. These retry.
  • DSBC* is Business Central itself. Unauthorized requests, endpoints not found, a server too busy.

If the failure shape is undiagnosed, it has no rule yet. Send it to support so one can be added rather than trying to reverse-engineer it.

3. Apply the fix and re-run​

Make the change the error calls for, then retry. You can retry a single transaction from within its connector's grid on the detail page, or retry from the list view directly.

For anything broader, BC troubleshooting is searchable by symptom rather than by code, which is the better entry point when you have a behavior rather than an error.

4. Archive what you are not going to fix​

If a failure is safe to ignore, archive it rather than leaving it in the list. You can archive everything at once or one appointment at a time.

This is worth doing rather than skipping. An errors page with a permanent backlog of known-ignorable failures stops being something anyone checks, and the next real failure hides in it.

Verify​

Confirm the retried transaction reaches a successful state, not merely that it left the errors list. Then re-run the original action end to end, since a transaction succeeding on retry and the workflow being correct are two different things.

Last updated on by Hendrik Bulens