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 below pairs 💡 (what it means) with 🛠️ (what to do).
Quick lookup
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:
- 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.
- Verify connector URL:
- Navigate to Administration > Connectors in Dime.Scheduler.
- Verify the web service URL is correct and accessible.
- 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).
- 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
- Go to Administration > Connectors in Dime.Scheduler.
- Edit the Business Central connector.
- Set authentication to the desired authentication method.
- 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.
BC insufficient permissions
⚙️
DSBC010fix configuration💡
BC returned a SOAP fault like
Sorry, the current permissions prevented the action. (Page 2087632 Dime DS Appointment Resources Resources Execute: ). The integration user authenticated successfully but lacks the permission set required to read/execute the page named in the parentheses. Distinct from DSCFG008 (HTTP 401/403 at the transport layer) and DSBC001 (WCF-level credential rejection) - here the user is recognized and the call gets through, but the AL permission check inside BC rejects it.🛠️
In BC, open Permission Sets, find the Dime.Scheduler permission set (or the one assigned to the integration user), and grant the missing object permission named in the fault. The fault names the exact page ID, type, and permission (Read/Insert/Modify/Delete/Execute) that's missing, so add that row.
BC lock timeout
🔁
DSBC011retried automatically💡
BC returned a SOAP fault like
We can't save your changes right now, because the data is being updated in a transaction done by another session. ... Please try again later.. The row the connector was writing was locked by another session's open transaction - pure contention, nothing misconfigured. The call succeeds once the lock clears.🛠️
Transient - retried automatically (5 attempts, 2s exponential backoff plus jitter, a longer curve than the standard transients because the fault warns the wait "may take a while"). If it persists, look for a long-running or stuck transaction on the BC tenant holding the lock - a hung NAS session, a manual posting, or another integration writing the same records.
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.
Unsupported connector configuration
⚙️
DSCFG010fix configuration💡
The connector record asks the factory for a combination it can't build - typically
AuthType or ApiType is None, or an auth flow Dime.Scheduler doesn't ship for that back-office (e.g. one of the disabled OAuth flows on NAV). The transaction message names the specific connector and the unsupported value (e.g. BC (SOAP) connector ACME: None is not supported.).🛠️
Open the connector settings and pick a supported Authentication type and API type for that back-office. Saving the connector without choosing one leaves it on
None, which is what trips this code.OAuth client rejected by Entra ID
⚙️
DSCFG011fix configuration💡
Entra ID (Azure AD) rejected the OAuth client credentials with
error: "invalid_client" - most commonly AADSTS7000215: Invalid client secret provided, but the same code also covers expired secrets, a wrong client_id for the tenant, or sending the secret ID instead of the secret value. The credential blob parsed fine (otherwise DSCFG006 would fire); the values just aren't accepted by AAD. Distinct from DSCFG008 (HTTP 401 from the back-office itself) - this one fires before any back-office call, at token acquisition.🛠️
Open the app registration in Entra ID, generate a fresh client secret, copy the Value (not the Secret ID), and paste it into the connector's OAuth credential blob under
client_secret. Re-save the connector. The AADSTS sub-code in the recorded message points at the exact reason (e.g. 7000215 = bad secret value, 7000222 = expired secret).HTTP endpoint not found
⚙️
DSCFG012fix configuration💡
The back-office returned HTTP 404 on a REST call. The host answered, but nothing is published at the URL Dime.Scheduler posted to. REST counterpart of
DSBC002 (EndpointNotFoundException on the SOAP path). Not retried - a 404 is a misconfiguration, not a transient blip.🛠️
Verify the connector's
WebServiceAddress. Common causes: a typo or stale environment in the URL, the OData API page is not published on the back-office, or the company segment in the OData path is wrong. Confirm the URL resolves to the published API page from the back-office service host.Entra ID tenant not found
⚙️
DSCFG013fix configuration💡
Entra ID rejected token acquisition with
AADSTS90002: Tenant '<id>' not found. The tenant in the configured OAuth authority doesn't exist, or has no active subscription. Fires at token acquisition, before any back-office call - distinct from DSCFG011 (bad/expired secret) and DSCFG008 (HTTP 401 from the back-office itself). Not retried - a wrong tenant won't self-heal.🛠️
Check the tenant ID in the connector's OAuth credential blob (the
token_endpoint / authority URL). Confirm it's the correct directory (Tenant) ID from the app registration's Entra ID overview, that you're pointing at the right cloud, and that the tenant has an active subscription.Entra ID app not in tenant
⚙️
DSCFG014fix configuration💡
Entra ID rejected token acquisition with
AADSTS700016: Application with identifier '<client_id>' was not found in the directory '<tenant>', or the older equivalent AADSTS70001: Application '<client_id>' is not registered for this tenant. The tenant exists (otherwise DSCFG013 would fire) and the secret was never evaluated - AAD couldn't find the app registration in that directory at all. Either the client_id belongs to a different tenant than the one in the authority, the app is single-tenant and hasn't been installed / admin-consented in this directory, or the client_id is stale (the registration was deleted or recreated). Fires at token acquisition, before any back-office call - distinct from DSCFG013 (tenant doesn't exist), DSCFG015 (app exists but service principal is disabled), and DSCFG011 (bad/expired secret). Not retried - a missing app registration won't self-heal.🛠️
Confirm the
client_id in the connector's OAuth credential blob matches an app registration that lives in the tenant configured in the authority URL. If the app is single-tenant, point the authority at its directory (Tenant) ID. If it's meant to be multi-tenant, have a tenant admin grant admin consent (https://login.microsoftonline.com/<tenant>/adminconsent?client_id=<client_id>) so the service principal is provisioned in that directory.App registration disabled
⚙️
DSCFG015fix configuration💡
Entra ID rejected token acquisition with
AADSTS7000112: Application '<client_id>'(<name>) is disabled. The app registration exists in the resource tenant (otherwise DSCFG014 would fire) but its service principal object is disabled there - Enabled for users to sign-in is set to No on the enterprise application. Per Microsoft's guidance, the disable can have been done by the resource tenant admin, by the app owner, or globally by Microsoft itself - so the remediation starts with finding out why it's disabled, not just flipping it back on. Fires at token acquisition, before any back-office call. Not retried - a disabled service principal won't self-heal.🛠️
Confirm with the resource tenant owner whether the disable was intentional. If it was (access deliberately revoked, or Microsoft globally deactivated the app), the integration stays broken until the underlying decision is reversed - don't just re-enable it. If it was a mistake, re-enable from the Entra portal (Enterprise applications > find the app by the client ID in the message > Properties > Enabled for users to sign-in = Yes), or via Microsoft Graph PowerShell:
Update-MgServicePrincipal -ServicePrincipalId <objectId> -AccountEnabled:$true. Once re-enabled, the next retry of the failed transaction will succeed without any connector change.Resource not consented in tenant
⚙️
DSCFG016fix configuration💡
Entra ID rejected token acquisition with
AADSTS500011: The resource principal named '<resource>' was not found in the tenant named '<tenant>', or the equivalent AADSTS650056: Misconfigured application variant. The connector's client app is fine (otherwise DSCFG014 would fire), but the resource the connector is requesting a token for - typically the Business Central API enterprise app - has no service principal in the customer's tenant. The resource app was never admin-consented into that directory, so AAD has nothing to issue a token to. Fires at token acquisition, before any back-office call. Not retried - missing consent won't self-heal.🛠️
Have a tenant admin grant admin consent to the resource app in the customer's tenant. For Business Central this is typically the BC API enterprise app - admin-consent it via
https://login.microsoftonline.com/<tenant>/adminconsent?client_id=<bc-resource-app-id> so its service principal is provisioned. Distinct from DSCFG014, which is about consenting the client app; here the client is fine and it's the resource that's missing. Once the resource service principal exists in the tenant, the next retry will succeed without any connector change.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.
HTTP proxy tunnel failure
🔁
DSHTTP002retried automatically💡
The outbound proxy returned a non-2xx response to the HTTPS
CONNECT request, so the tunnel to the back-office never opened. HttpRequestException.HttpRequestError is ProxyTunnelError; StatusCode is null because no response was received from the destination.🛠️
Transient - retried automatically. If it persists, the issue is the outbound proxy health (e.g.
proxy.internal.*.dimescheduler.com) rather than the back-office itself - escalate to Dime.Scheduler support.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.
- 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.
- Verify connector configuration:
- Navigate to Administration > Connectors.
- Check the Business Central system:
- Review the Dime.Scheduler Appointments table.
- Verify the web service endpoints are available and responding.
- Retry the transaction:
- After resolving the underlying issue, retry the failed transaction.