Setting up time registration
Time registration needs five things in place. Four are configuration in Dime.Scheduler; the fifth is the 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. extension that receives the time. The pages a resource and a team lead then work in are time tracking and timesheets.
1. A time sheet connectorโ
A connectorConnectorAn integration that links Dime.Scheduler to a back-office system, routing data in and scheduling decisions back out. tells Dime.Scheduler where a given source appSource appAn identifier Dime.Scheduler attaches to data so it can route a change back to the correct back-office system.'s data lives. Time registration needs one whose target is Time sheet.
This is a separate connector row from the one that carries appointments, even when both point at the same environment. They address different endpoints, so one connector cannot serve both. A tenant that integrates two companies needs one time sheet connector per source app.
Create it on the Connectors page with:
| Field | Value |
|---|---|
| Type | MS Dynamics 365 Business Central |
| Target | Time sheet |
| Enabled | On |
| API type | REST |
| Source app | Must match the source app of the jobs and tasks whose time you are registering |
| Web service URI | The time entry API endpoint published by the Business Central extension |
| Authentication | MS Entra ID, with the tenant ID, client ID and secret of an app registration that has access to the environment |
Two of these cause most of the failures:
Source app has to match. An entry inherits its source app from the task it is logged against. If a task's source app is CRONUSBE and the connector's is CRONUS, nothing links them and submission fails immediately with no time sheet connector is configured. This is the first thing to check.
REST is required. Time sheets are not carried over SOAP. A SOAP connector is rejected up front rather than after a round trip.
Check the environment name in the web service URI character by character. A typo there produces a Business Central error that reads like an authorization or availability problem rather than a wrong address, and it is easy to spend a long time on the wrong theory.
2. Resources with a back-office numberโ
The back office keys time sheetsTime sheet (Business Central)The Business Central record that registers hours per employee. Dime.Scheduler can fill it from the plan (planned time) or from released time entries (time registration); running both for the same work registers the hours twice. by resource numberResource numberThe identifier a resource carries in the back office. Time entries and other records are keyed on it, so a resource created by hand without one cannot have time registered., not by name and not by the Dime.Scheduler identifier. A resource without one cannot have time submitted, and the entry is rejected before it leaves.
Resources that came from the back office already have this. Resources created by hand in Dime.Scheduler may not.
3. Linking people to resourcesโ
A resourceResourceAn entity that can carry out work - a person, vehicle, tool, or room - that you schedule on the planning board. is a schedulable entity. A user is a login. They are separate concepts, and time registration is one of the places where the link between them matters: the page shows a person the time of the resources they are linked to, and it resolves that link through the email address.
If someone opens their time page and sees nothing to log against, the link is the first thing to check, before permissions. How the match is made is described on My Work.
4. Permissionsโ
Three user actionsUser actionA single protected capability, such as 'edit appointment', that a role can grant. The building block of role-based access control. govern the feature. They are independent, and the difference between the last two is a policy decision rather than a technical one.
| Action | Grants |
|---|---|
| Log own time | Log and submit time for the resources you are linked to. The doer's permission. |
| View timesheets | See every resource's time on the timesheets page. Read-only. |
| Log time on behalf | Perform a resource's own gestures for them from the timesheets page. |
Log time on behalf is a proxy permission, not an approval one. It lets a team lead submit for someone who is on holiday, and the audit trail names both people. It confers no power to alter, reject or hold anyone's time, because approval lives in the back office and no permission here reaches it. See roles and user actions for how they are assigned.
5. The Business Central extensionโ
The environment must expose the time entry API page from the Dime.Scheduler extension, and the app registration used by the connector must have access to it. The connector's web service URI points at that page.
Time registration is preview, so confirm the extension version deployed in the target environment publishes it before configuring the rest.
Verifying the setupโ
Work outward from the smallest thing:
- A resource logs one entry, one hour, on a task they are scheduled on.
- They submit it.
- Within seconds it should read In back office.
If instead it fails immediately, the message names the cause. These checks run before anything is sent:
| Message | Fix |
|---|---|
| No time sheet connector is configured for this back office | Create a time sheet connector whose source app matches the task's. |
| Time sheets need a Business Central REST connector | Change the connector's API type to REST. |
| The resource has no back-office number | Set the resource's back-office number. |
Everything past that point is the back office's verdict. If it is rejected by Business Central, the message is BC's own and usually names a closed period or a missing employee link. The statuses an entry passes through, and what each asks of you, are on the timesheets page.
When nothing is coming backโ
If entries submit without an immediate error but stay in Submitting across every resource and every task, stop looking at the entries. Nothing about a single line produces that pattern, and retrying will not clear it.
The submission left Dime.Scheduler and nothing answered. In practice that means one of:
- the service that carries time sheet submissions is not running, or is running a build that predates time registration
- the messaging subscription it listens on does not exist in that environment
- the environment is not on a deployment that includes the feature
All three are operational rather than configuration, and all three look identical from inside the application. This is worth knowing before you spend time re-checking a connector that is in fact correct.
The entries themselves are safe throughout. They stay in Submitting, and nothing is marked failed on a guess: Dime.Scheduler only records an outcome the connector reported. How that hand-off works is on the timesheets page.