Transaction Errors

When an appointment sync to Business Central fails, the failed transaction shows up on the Errors page with a message prefixed by a stable code in square brackets, e.g. [DSBC003] BC server too busy. The code never changes once issued, so you can search transactions or logs for [DSBC003] to find every appointment that hit the same failure.

Retried codes are picked up automatically by the retry job (3 attempts, exponential backoff with jitter, then the row stays Failed for the next pass). Fix configuration codes need a connector or back-office setup change first - they are not retried. Undiagnosed failure shapes should be sent to support so a rule can be added.

Each section pairs 💡 (what it means) with 🛠️ (what to do).

Quick lookup

Code	Goes to	Retry
DSCFG001	Back-office not allowed	fix config
DSCFG002	Missing required field	fix config
DSCFG003	Back-office returned no data	fix config
DSCFG004	Schema mismatch	fix config
DSCFG005	Wrong system type	fix config
DSCFG006	OAuth credentials unparseable	fix config
DSCFG007	Malformed connector URL	fix config
DSCFG008	HTTP request unauthorized	fix config
DSCFG009	HTTPS required for SOAP	fix config
DSHTTP001	HTTP transient (429/5xx)	retried
DSBC001	HTTP request unauthorized	fix config
DSBC002	BC endpoint not found	fix config
DSBC003	BC server too busy	retried
DSBC004	Request channel timeout	retried
DSBC005	BC communication fault	retried
DSBC006	SOAP "unknown type" fault	fix config
DSBC007	SOAP "service not found" fault	fix config
DSBC008	BC REST API missing Location header	fix config
DSBC009	SOAP HTTP transient (429/5xx)	retried
DSDB001	SQL transient	retried
DSDB002	Database access	retried
DSDB003	Concurrency conflict	retried
DSDB004	SQL timeout	retried
DSUNK001	Undiagnosed	undiagnosed

Request channel timeout

The request channel timed out attempting to send after 00:01:00. Increase the timeout value passed to the call to Request or increase the SendTimeout value on the Binding. The time allotted to this operation may have been a portion of a longer timeout. The HTTP request to 'http://[server]/[instance]/WS/[company]/Page/Appointment' has exceeded the allotted timeout of 00:01:00.

🔁DSBC004DSHTTP001retried automatically

💡

The WCF channel timed out before BC responded. The operation may have completed on BC's side regardless. The most common cause is that the web service is not accessible from Dime.Scheduler, typically due to firewall restrictions blocking the connection. Other causes: network latency, BC server under heavy load, large payloads, slow database queries on the BC side, or complex AL business logic.

🛠️

Transient - retried automatically. If it persists:

1. Check firewall and network accessibility:
   • Verify the Business Central web service URL is accessible from the Dime.Scheduler cloud.
   • Open the required firewall ports to allow traffic from Dime.Scheduler to Business Central.
   • On-premises: ensure the web service endpoint is published and accessible externally.
   • Cloud: verify the service is not blocked by network security groups or Azure firewall rules.
   • Test connectivity using tools like telnet, curl, or a browser from the Dime.Scheduler cloud.
2. Verify connector URL:
   • Navigate to Administration > Connectors in Dime.Scheduler.
   • Verify the web service URL is correct and accessible.
3. Increase the timeout if connectivity is confirmed:
   • Edit the Business Central connector.
   • Increase the Request Timeout value (for example, from 60 to 120 seconds or higher).
4. Optimize Business Central performance:
   • Review and optimize custom code in the appointment processing codeunits.
   • Check for database locks or slow queries.
   • Review the Business Central server event logs for performance issues.

tip

If timeouts occur frequently during specific times of day, this often indicates server load issues. Consider scheduling heavy processing tasks outside of peak planning hours.

HTTP request unauthorized

The HTTP request is unauthorized with client authentication scheme 'Anonymous'. The authentication header received from the server was 'Basic realm=...'

Variations include 401 Unauthorized and Invalid credentials.

⚙️DSBC001DSCFG008fix configuration

💡

DSBC001 - WCF rejected the SOAP-level credentials (the configured username/password is wrong or the security mode doesn't match what BC expects). DSCFG008 - the back-office returned HTTP 401 or 403 to the REST/OAuth path. The authentication method configured on the connector does not match what Business Central expects, or the credentials are incorrect or expired.

🛠️

Step 1 - Check the BC version

• Business Central Cloud (SaaS) - use OAuth 2.0.
• Business Central On-Premises - use Basic Authentication, Windows/NTLM, or OAuth 2.

Step 2 - Fix the authentication

1. Go to Administration > Connectors in Dime.Scheduler.
2. Edit the Business Central connector.
3. Set authentication to the desired authentication method.
4. Fill in the required authentication fields.

Using OAuth 2?

Follow the OAuth setup guide.

Using Basic auth?

If the test fails with the wrong password, verify the account is not locked in Active Directory or Business Central.

Step 3 - If the test still fails

Check these common issues:

Problem	Fix
OAuth: "Client secret expired"	Generate a new secret in Azure Portal and update the connector
OAuth: "Invalid tenant ID"	Verify the tenant ID matches your Azure AD tenant
Basic Auth: "Invalid username"	Try without the domain prefix (just USERNAME)
Basic Auth: "Account locked"	Unlock the account in Active Directory or BC
"Permission denied"	Verify the account has access to Dime.Scheduler tables

Step 4 - Retry the failed transaction

Once the test connection succeeds, retry the failed appointment from the Errors page.

BC endpoint not found

⚙️DSBC002fix configuration

💡

No SOAP listener answered at the configured URL. WCF raises EndpointNotFoundException for both "host unreachable" (DNS failure, tunnel offline, connection refused, port closed) and "host answered with 404" - the URL or the service is wrong.

🛠️

Verify the BC SOAP endpoint URL (typically ending in /WS/<Tenant>/Page/<PageId>) and that the host is reachable from the back-office service. The page may be unpublished, the BC tenant may be down, or the URL may be pointing at a stale environment.

BC server too busy

🔁DSBC003retried automatically

💡

BC's SOAP layer responded with ServerTooBusy. The BC tenant is at capacity.

🛠️

Transient - retried automatically. If it keeps happening, contact BC support about tenant throttling.

BC communication fault

🔁DSBC005retried automatically

💡

A network blip (connection reset, socket EOF, or I/O error) interrupted the SOAP call.

🛠️

Transient - retried automatically. If it persists, network or proxy investigation needed.

SOAP "unknown type" fault

⚙️DSBC006fix configuration

💡

BC returned a SOAP fault like The type X is unknown. - usually because the published AL extension is out of date and no longer matches the WSDL the connector was generated against.

🛠️

Republish the AL extension on the BC tenant.

SOAP "service not found" fault

⚙️DSBC007fix configuration

💡

BC returned Service "X" was not found! - the SOAP URL is correct but the requested page (Page/Appointment) is not exposed at that URL.

🛠️

Publish the missing page in BC's Web Service registry, or correct the page reference in the connector URL.

BC REST API missing Location header

⚙️DSBC008fix configuration

💡

The BC REST API created the appointment but the response didn't include a Location header pointing at the new record - so Dime.Scheduler can't post the follow-up process call.

🛠️

The appointment record was likely created on BC; either trigger the BC-side process action manually, or check why BC isn't returning a Location header (custom AL code stripping it, reverse proxy rewriting it, etc.).

SOAP HTTP transient (429/5xx)

🔁DSBC009retried automatically

💡

The BC SOAP call surfaced as ProtocolException with The remote server returned an unexpected response: (NNN) ... where NNN is 429/502/503/504. BC's HTTP front-end (or a proxy/load-balancer in front of it) is temporarily unhealthy. SOAP-path counterpart of DSHTTP001.

🛠️

Transient - retried automatically. If it persists, check BC tenant health, Azure front door, or any reverse proxy in front of BC.

HTTPS required for SOAP

⚙️DSCFG009fix configuration

💡

The BC SOAP WebServiceAddress uses http://, but BC's SOAP binding requires Transport security (HTTPS). WCF refuses to open the channel and raises ArgumentException: The provided URI scheme 'http' is invalid; expected 'https'. (Parameter 'via').

🛠️

Change the connector URL to https://. BC Online only publishes the SOAP endpoint over HTTPS; on-prem BC must have the SOAP service configured with SSL.

Back-office not allowed

⚙️DSCFG001fix configuration

💡

The back-office system was reached but is not configured to accept appointments from Dime.Scheduler (e.g. Send appointment to web service is off, or the back-office side rejected the call as not allowed).

🛠️

Open the connector settings, ensure outbound is enabled and the back-office side has the receiving page/extension installed.

Missing required field

⚙️DSCFG002fix configuration

💡

The data Dime.Scheduler sent was rejected as invalid input by the connector. Usually a missing required field on the appointment payload.

🛠️

Check the appointment for required field values that the back-office expects. Common culprits: empty JobNo/TaskNo when the back-office requires them.

Back-office returned no data

⚙️DSCFG003fix configuration

💡

The back-office returned no data when Dime.Scheduler asked for an appointment by ID. The appointment doesn't exist on the back-office side.

🛠️

Confirm the appointment was actually created on the back-office, and that the IDs match.

Schema mismatch

⚙️DSCFG004fix configuration

💡

The back-office returned data in a type Dime.Scheduler didn't expect. Usually a schema mismatch after an extension update on the back-office side.

🛠️

Republish the AL extension on BC (or equivalent) so the back-office schema matches what the connector expects.

Wrong system type (REST vs SOAP)

⚙️DSCFG005fix configuration

💡

The connector URL points to a back-office that isn't the right kind of system. E.g. an OData REST URL pointed at a SOAP-only endpoint.

🛠️

Verify the WebServiceAddress on the connector matches the API type (SOAP vs REST) selected on the connector record.

OAuth credentials unparseable

⚙️DSCFG006fix configuration

💡

The OAuth credential string couldn't be parsed. The connector's password field stores the OAuth client config as a key=value;key=value blob and one of the required keys (client_id) is missing or the blob has no semicolons.

🛠️

Re-enter the OAuth credentials in the connector settings; ensure all required keys (client_id, client_secret, token_endpoint) are present and semicolon-separated. The OAuth setup guide walks through the full flow.

Malformed connector URL

⚙️DSCFG007fix configuration

💡

The WebServiceAddress is not a valid URI (typos, missing scheme, illegal characters).

🛠️

Open the connector settings and fix the URL.

HTTP transient (429/5xx)

🔁DSHTTP001retried automatically

💡

The back-office returned HTTP 429 (Too Many Requests), 502, 503, or 504. The server is busy or down. The Retry-After header is honored if present.

🛠️

Transient - retried automatically. If it persists, check the back-office status page or tenant-level throttling.

SQL transient

🔁DSDB001retried automatically

💡

SQL Server returned one of Microsoft's documented transient error numbers (deadlock victim, throttling, connection reset, etc.).

🛠️

Transient - retried automatically. If it persists, contact Dime.Scheduler support.

Database access

🔁DSDB002retried automatically

💡

A repository-level access failure (connection lost, query aborted).

🛠️

Transient - retried automatically.

Concurrency conflict

🔁DSDB003retried automatically

💡

Two requests tried to update the same record at the same time and one lost the race.

🛠️

Transient - retried automatically. If it keeps happening on the same appointment, there's an integration loop somewhere.

SQL timeout

🔁DSDB004retried automatically

💡

SQL command timeout - the query took longer than the configured limit.

🛠️

Transient - retried automatically. If chronic, contact Dime.Scheduler support about index/query performance.

Undiagnosed

🚨DSUNK001undiagnosed

💡

An exception that doesn't match any known rule reached the pipeline. It was logged for the maintainers and recorded as Failed so the RetryService picks it up later.

🛠️

Send the transaction ID and full error message to Dime.Scheduler support - this code means we haven't seen this failure mode before and need to add a rule for it.

General troubleshooting steps

When encountering transaction errors, follow these steps. For more detailed guidance, see the Business Central Troubleshooting guide.

1. Check the transaction details:
   • Navigate to Administration > Transactions > Errors.
   • Click on the failed appointment to view detailed error information.
   • Review the error message - the code in square brackets at the start maps to a section above.
2. Verify connector configuration:
   • Navigate to Administration > Connectors.
3. Check the Business Central system:
   • Review the Dime.Scheduler Appointments table.
   • Verify the web service endpoints are available and responding.
4. Retry the transaction:
   • After resolving the underlying issue, retry the failed transaction.