General
The 'Dime.Scheduler Setup' page holds two settings that the FastTrack wizard doesn't expose:
- Check appointments on delete
- Notify appointment errors
This page explains what each one does and when to switch it on.
You can find the wizard by looking for Dime.Scheduler Setup in the search bar.
Check appointments on delete
A common mistake is removing an order from Business Central that still has planning in Dime.Scheduler. When that happens, Business Central shows a message like this:
The specified job JOB12345 cannot be deleted because it is associated with existing appointments. Please remove the appointments first, or retry this command with CheckAppointments set to 0.
The message already points to the fix. Dime.Scheduler's API exposes a CheckAppointments flag on both the job and task delete endpoints, which decides whether to verify it is safe to remove the job before losing any planning data:
- When set to true, the message above is thrown and the job is not removed from Dime.Scheduler.
- When switched off, the job is removed along with all underlying tasks and planned appointments.
The global Check appointments on delete setting is read by the Dime.Scheduler extension in BC and passed along with every request to remove tasks and jobs. It applies globally, but you can override it with custom extensions built on top of Dime.Scheduler's extension in Business Central.
Notify appointment errors
Dime.Scheduler keeps a trail of every interaction it initiates with connected backoffice systems like Business Central, Exchange, and webhook connections. This audit trail is available inside Dime.Scheduler itself.
When Dime.Scheduler successfully posts data to the connected system, it marks that transaction as successful. In Business Central, a successful transaction means all data is written to the Dime.Scheduler Appointments table. This is the staging table Dime.Scheduler writes to. A routing table (the Dime.Scheduler Source Types list) then invokes a code unit whenever a new item is added to the list (an insert, update, or removal of an appointment in Dime.Scheduler), which processes the planning information Dime.Scheduler provided.
An item landing in the staging table doesn't guarantee that the connected system processed the appointment itself, and there are many reasons why it might fail. In the image below, for example, the assigned resource is missing a 'Unit of Measure':
As a result, the status of this appointment in BC is Error. Planners may wonder why the appointment isn't showing up in the expected tables. The staging table is available for diagnostics, but the 'Notify appointment errors' switch in the Dime.Scheduler setup is a more user-friendly option.
When this flag is set to true, any error produced in BC is sent back to Dime.Scheduler as a 'Notification':
So even when Dime.Scheduler considers the item sent successfully to Business Central, the appointment may not have processed exactly right in the backoffice system. Turning on this switch removes that confusion by surfacing the failure to the planner.
Here is how the transaction system works in Dime.Scheduler in tandem 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.