Connectors

A connectorConnectorAn integration that links Dime.Scheduler to a back-office system, routing data in and scheduling decisions back out. is how Dime.Scheduler talks back to the system that owns the work. When a planner schedules a task on the board, that change has to flow back to the system the job came from - Business Central, NAV, a Power Automate flow, whatever the source is - or the rest of the business never finds out the work was planned. A connector is the configured link that makes that round-trip happen.

One tenant can have many connectors. Most do: a single Dime.Scheduler instance often serves multiple companies inside the same ERP, multiple regional installs of the same ERP, or a mix of an ERP and a webhook-based system. Each gets its own connector entry, each with its own credentials, each scoped to a specific source.

What identifies a connector

Beyond housekeeping (a name and description so you can tell them apart), the connector form asks for two kinds of information: where to send data and how to authenticate when you get there. Everything else flows from those two questions.

Where to send data

Three fields decide where:

• Type is the back-office system family the connector targets:

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

• Web Service URI is the endpoint Dime.Scheduler posts to.

• API Type picks the protocol within the family. Some types support more than one:

  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

The Enabled flag is the on/off switch. When off, the connector is registered but ignored - useful for staging a new connector before going live, or temporarily silencing a source during maintenance.

Bi-directional message flow

What you configure here only covers the flow from Dime.Scheduler to the back-office system. The opposite direction (getting data into Dime.Scheduler) is set up in that system itself. The supported integrations Dime Software manages on the customer's behalf:

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

How records get matched back

When several back-office systems share one tenant, every record needs to say where it came from - otherwise Dime.Scheduler has no way to tell which connector should receive an update. The source appSource appAn identifier Dime.Scheduler attaches to data so it can route a change back to the correct back-office system. is that identifier: a unique tag stamped on every record at the moment it arrives, that travels with the record forever afterwards.

Each connector declares the source app it owns. When the planner makes a change, Dime.Scheduler reads the source app off the record and fires every connector that has a matching source app. Run the simulation below to see this match-and-dispatch step in action:

Source app routing

Open tasks

Service order S-1042BC-USA

Service order S-2087BC-CANADA

Alice Martin · Mon

1Schedule

2Match source app

3Deliver

Drag a task onto Alice’s lane to schedule it. We take over from there.

Limiting the connector's scope

The Crud type lets you restrict a connector to specific operations - create only, update only, delete only, or any combination. Use it when one source needs different downstream behaviour per operation (a Power Automate flow that only fires on create, a separate notification connector that only fires on delete).

Authentication

The back office decides what authentication it accepts; Dime.Scheduler supports the common shapes.

Basic authentication

Just a login and password.

Windows authentication (NTLM, Kerberos)

Just a login and password. Not supported by the REST API.

MS Entra ID

Needs three values:

• Tenant ID
• Client ID
• Client Secret

OAuth2

Any OAuth2-capable identity provider works. The supported grant type is client-credentials, in two flavours:

• Client secret basic - credentials go in the HTTP Basic Authentication header.
• Client secret post - credentials go in the request body.

Both need the same details:

• Authorization Server - the endpoint Dime.Scheduler calls first to exchange credentials for a token.
• Client ID - the app registration in the OAuth2 provider.
• Client Secret - that app's secret value.
• Scope - optional, space-delimited values Dime.Scheduler needs to post back to the web service URL.

Picking an authentication method

OAuth2 and MS Entra ID (which is OAuth2 underneath) are the industry standard and what you should reach for first. With OAuth2, client secret basic is the safer of the two flavours - prefer it unless the back office only accepts the post variant.

Basic Authentication is the fastest way to get a test integration working. Windows / NTLM is fine on-prem when Active Directory is set up properly on the NAV/BC server. Both are older methods the industry has moved away from, so use them only when OAuth2 or MS Entra ID isn't an option.

Reference: what each connector type supports

Authentication methods:

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

Data formats:

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

REST/JSON is preferred where it is available; it is the modern default.

Back-office-specific connector setup

For the system-specific details:

• Business Central
• NAV
• Power Automate
• Webhook