Transactions
Every time Dime.Scheduler talks to a connected backofficeBack 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. system - Business Central, Exchange, or a webhookWebhookThe generic connector that POSTs every appointment change as JSON to a URL you choose. It delivers the message and leaves interpretation to the receiving system. connection - it records the interaction. This page explains how those 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. work and what "successful" really means, so you can read the audit trail inside Dime.Scheduler with confidence.
What constitutes a transaction
When Dime.Scheduler posts data to a connected system, it marks the transaction as successful. What that means in practice differs per backoffice system, but the rule Dime.Scheduler applies is the same everywhere: a 200 HTTP status code.
In the connectorConnectorAn integration that links Dime.Scheduler to a back-office system, routing data in and scheduling decisions back out. for Business Central, a successful transaction means an item has been posted to the Dime.Scheduler Appointments table, which internal Business Central workflows then pick up. This is a robust pattern that maximizes the resilience of the solution. Other backoffice systems may not have this proxy and process the request immediately. The exact behavior depends on your setup.
To repeat: all Dime.Scheduler looks at to mark a transaction as successful is a 200 HTTP status code in the response. That does not necessarily mean the new planning information was processed successfully. It only means Dime.Scheduler reached the endpoint and the endpoint responded.
Processing the planning data in the backoffice system
A decoupled solution - like the staging 'Dime.Scheduler Appointments' table approach in BC - introduces a second layer of complexity. The backoffice can acknowledge that it received the appointment correctly by returning a 200 code, yet still fail to process that appointment internally.
The item may land in the staging tableStaging tableThe Dime.Scheduler Appointments table in Business Central where incoming appointments land first. Business Central processes rows from there, so a row can be received and still fail processing. but never make it into the target tables. There are many reasons why. In the image below, for example, the assigned resource is missing a 'Unit of Measure' in Business Central:
The status of this appointment in BC is therefore Error. So even when Dime.Scheduler considers the item sent successfully, the appointment may not have processed correctly in the backoffice system.
For help troubleshooting issues like this, see the Business Central Troubleshooting guide and the Business Central Transaction Errors reference.
To keep planners informed when this happens, Dime.Scheduler can create notifications for appointments:
Summary
Here is how the transaction system works in Dime.Scheduler together with Business Central. Step through the happy path on the USA tenant and then the failure case on the Canadian tenant:
USA tenant sends work
The USA Business Central tenant pushes its jobs, tasks, and resources into Dime.Scheduler. Every record is tagged with a Source App so it can be routed back to the right tenant later.
Automatic retries
Dime.Scheduler's job is done once the backoffice system returns a 200 status code. When any other status code comes back, automatic retry policies may kick in and make a few more attempts to reach the backoffice system. Transient errors like request timeouts (408), throttling (429), bad gateway (502), unavailable services (503), and gateway timeouts (504) are often one-off or temporary, so a second or third attempt might succeed.
A transaction can originate from three sources:
- Service: initiated by the user in the regular flow of planning appointments on the planning boardPlanning boardThe main graphical scheduling surface where dispatchers drag tasks onto resources across a timeline..
- Website: triggered by the retry button on the transactions page.
- Timer job: automatic retries for appointments in a failed status.
As soon as someone changes the planning, Dime.Scheduler calls the connected systems. If that transaction fails, the automatic retry job runs in the background and retries every appointment in a state that could still return a successful response. It makes 5 attempts, then suspends further retries on the assumption that a sixth attempt would not change the outcome.
If all attempts fail, or if the administrator changed the connector or the backoffice system itself, they can also manually retry from the detail page of the appointment. The transaction source reads 'website' for this action.