Diagnose a failed Business Central sync
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 codeTransaction error codeA stable code such as DSBC003 that a connector attaches to a failed transaction. Codes never change once issued, so one can be looked up on the transaction errors reference page of its connector. 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 transactionsTransactionThe recorded call Dime.Scheduler makes to a connected system when the planning changes. It counts as successful on an HTTP 200, which means the endpoint received it, not that the back office processed it. and logs to find every appointmentAppointmentA task scheduled to a resource for a specific period - the scheduled instance you see on the planning board. 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
Failedfor 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 connectorConnectorAn integration that links Dime.Scheduler to a back-office system, routing data in and scheduling decisions back out. or back-officeBack officeThe ERP or business system Dime.Scheduler plans for - most often Microsoft Dynamics 365 Business Central. It owns the master data and remains authoritative over what it receives. 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.
Related
- Connect Business Central for the setup this diagnoses.
- The outbound queue logs everything BC sends, which is what you want configured before the next incident.