Connectors

A single instance of Dime.Scheduler is able to connect with multiple back-office applications. A back-office application is an umbrella term for any system that can be used to provide data for planning. Many of these systems allow you to create multiple companies, business units, operational units, etc. Each of these organizational entities can be a data source for Dime.Scheduler.

An entry in the connector setup represents such an endpoint, which you can configure how Dime.Scheduler must use it to write back planning data.

Three categories of data can be identified in the setup of a connector:

• Basic info
• Connector info
• Authentication info

Basic info

The following fields are merely for informational purposes to help you manage the systems to link to Dime.Scheduler:

• Name
• Description

Connector info

The second field group identifies what kind of system we're dealing with.

Type

The following back-office system types are supported:

• Microsoft Dynamics 365 Business Central
• Microsoft Dynamics NAV
• Webhook

Enabled

When set to true, Dime.Scheduler will send back planning data to this back-office system for those appointments whose source type matches the connector's source type. Conversely, when set to false, Dime.Scheduler will ignore this connector.

Web Service URI

This is the endpoint where Dime.Scheduler will attempt to post data back to.

API Type

Some back-office system types support more than one API type:

Back-office system	Supported types	Comment
Microsoft Dynamics 365 Business Central	SOAP web services API pages	Read more here.
Microsoft Dynamics NAV	SOAP web services	Read more here.
Webhook	REST

Bi-directional message flow

Remember that the setup that's configured here only covers the message flow from Dime.Scheduler to the back-office system. The opposite message flow still needs to be configured in said system to get data in Dime.Scheduler.

Here is the list of backoffice system types that Dime Software manages and supports on the customer's behalf:

• Webhook
• Power Automate
• Microsoft Dynamics NAV
• Microsoft Dynamics 365 Business Central

See below for an overview of the supported data formats and authentication methods.

Source type

In order to send data back from Dime.Scheduler to these source applications, connection info needs to be specified.

The concept of a source application is crucial in Dime.Scheduler, and it's worth revisiting its definition.

Since multiple back-office systems can connect to the same Dime.Scheduler instance, there arises a conflict regarding unique data records. To address this data integrity concern, we've introduced an additional dimension called the source application identifier. A source app serves as a unique identifier, indicating the origin of a record. When you make a task or resource available in Dime.Scheduler, we can identify the system from which that record originates. This information is essential for directing planned task data to the appropriate system whenever the schedule is modified by planners.

In essence, the source app acts as the link facilitating bi-directional communication between a back-office system and Dime.Scheduler. When utilizing the standard connectors provided by Dime Software, you'll be prompted to enter a source app value. This value is crucial because, when planning a task for this source application, Dime.Scheduler will activate all the connectors associated with that particular source app.

Crud type

When desired, you can only accept certain types of data manipulation, which can be either create, update, or remove an appointment. For instance, you could use a separate connector with a single CRUD type to send out a different kind of email through a Power Automate flow.

Authentication

Dime.Scheduler supports a myriad of authentication mechanisms that the back-office system requires.

Basic authentication

All that is required is a login and password field.

Windows authentication (NTLM, Kerberos)

All that is required is a login and password field. Windows authentication is not supported in the REST API.

MS Entra ID

To use MS Entra ID to authenticate with, we need the following information:

• Tenant ID
• Client ID
• Client Secret

OAuth2

Any identity provider that supports OAuth2 can be used for this flow.

The client credentials grant type is supported and offers two authentication types:

• Client secret basic: credentials are sent in the HTTP authentication header using the HTTP Basic Authentication scheme.
• Client secret post: credentials are sent within the body of the request.

Both types require the same kind of information:

• Authorization Server: the endpoint that Dime.Scheduler must connect to first to provide some credentials and get back a token.
• Client ID: the app registration in the OAuth2 provider
• Client Secret: the secret value for said app
• Scope: optional list of space-delimited values that Dime.Scheduler needs to have to post data back to the web service URL

Don't know which one to choose?

OAuth2 and MS Entra ID (which implements OAuth2) are the de facto standard in the industry to authenticate and authorize users and systems. If possible, go for these. When you go for OAuth2, the current consensus is that the client secret basic authentication type is considered the most safe of the two.

For quick tests, Basic Authentication is the quickest way to get started. NTLM and Windows are equally fine if Windows AD is configured properly on the NAV/BC server. These authentication types are older and have been replaced by OAuth2 by the industry, so we'd advise you to only consider these when OAuth2 or MS Entra ID isn't possible.

The supported authentication methods for the standard connectors for Dime.Scheduler are listed below:

Connector	Basic Auth	Windows Auth	NTLM	MS Entra ID	OAuth2: Basic Auth	OAuth2: Body Auth
NAV	✅	✅	✅	❌	❌	❌
Business Central on-prem	✅	✅	✅	✅	✅	✅
Business Central cloud	✅	❌	❌	✅	✅	✅
Webhook	✅	❌	❌	✅	✅	✅

The following data formats are supported:

Connector	SOAP	JSON
Business Central on-prem	✅	✅
Business Central cloud	✅	✅
NAV	✅	❌
Webhook	❌	✅

REST/JSON is the preferred option, as it too is considered the default in the industry.