Transaction Errors

When an appointmentAppointmentA task scheduled to a resource for a specific period - the scheduled instance you see on the planning board. sync to Business Central fails, the failed transactionTransactionThe 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. shows up on the Errors page with a message prefixed by a stable 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, 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 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. 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

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
DSCFG010	Unsupported connector configuration	fix config
DSCFG011	OAuth client rejected by Entra ID	fix config
DSCFG012	HTTP endpoint not found	fix config
DSCFG013	Entra ID tenant not found	fix config
DSCFG014	Entra ID app not in tenant	fix config
DSCFG015	App registration disabled	fix config
DSCFG016	Resource not consented in tenant	fix config
DSHTTP001	HTTP transient (429/5xx)	retried
DSHTTP002	HTTP proxy tunnel failure	retried
DSHTTP003	HTTP connection failure	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
DSBC010	BC insufficient permissions	fix config
DSBC011	BC lock timeout	retried
DSBC012	BC no reply	retried
DSBC013	BC gateway JSON error	retried when transient
DSBC014	BC record modified	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.

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.

BC no reply

🔁DSBC012retried automatically

💡

WCF raised a bare CommunicationException with The server did not provide a meaningful reply; this might be caused by a contract mismatch, a premature session shutdown or an internal server error. The reply channel came back empty because the server closed the connection mid-request without sending a SOAP envelope. Unlike DSBC005 there is no inner I/O exception; the failure originates at the WCF channel itself. For an established connector this is a premature session shutdown (a BC app-pool recycle, a session or idle timeout, a server restart, or a proxy dropping a long SOAP call) rather than the contract mismatch the message also warns about: a genuine contract mismatch would fail every call, not sporadically.

🛠️

Transient - retried automatically (3 attempts, exponential backoff with jitter). If it persists for one tenant, look at the BC IIS application pool recycle settings and connectionTimeout, and at any reverse proxy or load balancer idle timeout in front of BC. If the same call fails on every attempt across retries, suspect an actual contract mismatch - a stale WSDL or AL extension - and republish the BC web service.

BC gateway JSON error

🔁DSBC013retried automatically

💡

WCF raised a ProtocolException with The content type application/json of the response message does not match the content type of the binding (text/xml; charset=utf-8), and the first bytes of the response are a JSON body like { "statusCode": 500, "message": "Internal server error", "activityId": "..." }. The API gateway in front of BC's SaaS service tier failed before producing a SOAP envelope and returned its JSON error page instead. The SOAP request never reached the AL runtime. The embedded statusCode carries the real HTTP status.

🛠️

If the embedded status is transient (408, 429, 502, 503 or 504) this is retried automatically, like DSBC009. A 500 is not retried. If it persists, check BC tenant health in the admin center, and quote the activityId from the response body when opening a Microsoft support case: it is their correlation ID.

BC record modified

🔁DSBC014retried automatically

💡

BC returned a SOAP fault like Another user has modified the record for this DS Appointment after you retrieved it from the database. Enter your changes again in the updated window, or start the interrupted activity again. This is BC's optimistic concurrency check: the record version changed between the AL code's read and its modify, because another session committed a write to the same row mid-call. Typically that is the BC job queue draining the staging table, a user editing in the client, or a second Dime.Scheduler transaction for the same appointment. Distinct from DSBC011, where the competing transaction is still open and blocks the write; here it already committed and only the version check failed.

🛠️

Transient - retried automatically (3 attempts, exponential backoff with jitter); the retry re-reads the record at its current version and succeeds. If it keeps happening on the same appointment, look for a competing writer touching the DS staging records in lockstep with Dime.Scheduler: a job queue entry processing the staging table on a tight schedule, or an integration loop sending the same appointment twice.

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 on the Dime.Scheduler side rather than in the back-office - escalate to Dime.Scheduler support.

HTTP connection failure

🔁DSHTTP003retried automatically

💡

A connection-level failure where no HTTP response could be parsed. HttpRequestException.HttpRequestError is InvalidResponse, ResponseEnded or ConnectionError, and StatusCode is null. The typical symptom is Received an invalid status line: '0'.: a stale pooled connection where the leftover chunk terminator of a previous response is misread as the next response's status line. The HTTP client only retries on its own when no bytes were received, so once a stray byte arrives the parse error surfaces here instead.

🛠️

Transient - retried automatically on a fresh connection. If it persists, suspect a reverse proxy or load balancer in front of the back office that half-closes keep-alive connections or mis-frames responses.

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.

A recipe uses this page

• Diagnose a failed Business Central syncFind the failing transaction, read the error, and apply the right fix.