Time
Planning says what should happen. Time says what did. Almost everything else in this manual is about the first. These pages are about the second: how a resourceResourceAn entity that can carry out work - a person, vehicle, tool, or room - that you schedule on the planning board. records the hours they actually spent, how a team lead checks that nothing is missing, and how those hours leave Dime.Scheduler for the system that costs and invoices them.
Two records, not one
Dime.Scheduler keeps two separate records of time, and most of what the pages in this section do follows from the difference.
A sessionTime sessionAn observation that a resource was working, travelling or waiting on a task between two moments. Sessions support a time entry and never reach the back office on their own. is an observation. A timer ran against a taskTaskA unit of work that belongs to a job. It appears in the open task list until it is scheduled to a resource. from one moment to another, or somebody wrote down that it did. Sessions are evidence. They can be corrected, and on their own they go nowhere.
A time entryTime entryA claim of a resource's time on one task for one calendar day. This is the record that is submitted to the back office, where it becomes a time sheet line. is a claim: the hours a resource says they spent on a task on a given day. Entries are what 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. costs, and an entry is what becomes a time sheetTime 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. line there.
Turning finished sessions into an entry is called claimingClaimThe act of turning finished work sessions into a time entry for one task and one day. A claim can also be made directly without a session; only work sessions count, travel and waiting do not.. The separation is deliberate. Recording what happened and deciding what to bill are two different acts, and a timer somebody forgot to stop should not quietly become an invoice. Sessions also carry a type, work, travel or waiting, and only work rolls up into a claim, so a day of driving is visible without becoming a day of billable labour.
The gap between the two records is where most surprises live. Work that was tracked but never claimed is the usual reason a week looks too thin, and both the resource's own page and the team lead's overview are built to surface it.
Who does what
Three hands touch an hour on its way out.
The resource tracks and claims. They run the timer, correct it where it was wrong, confirm what it suggests, type in what it never saw, and release the week. They do that from My Work in the browser or from the mobile app, and the time tracking page describes it.
The team lead reviews. Across every resource at once, they see what was logged, what is missing, what was tracked but never claimed, and what failed on its way out, and they can act for a resource who is not there to fix their own week. That is the timesheets page.
The back office approves. Dime.Scheduler never approves time. Releasing an entry hands it over, and whether it is accepted is decided in the system that owns costing. That boundary is deliberate, because approval has a financial consequence and belongs where the money is.
Where it goes
A released entry is queued for the connectorConnectorAn integration that links Dime.Scheduler to a back-office system, routing data in and scheduling decisions back out., which registers it in the back office as a time sheet line and reports back what happened. From then on the entry is locked in Dime.Scheduler, and its status tracks what the back office did with it. The lifecycle, and what each status asks of you, is on the timesheets page.
This is one of two routes by which hours reach the back office. The other registers the plan itself: what was scheduled is what gets booked, without anybody tracking anything. The Business Central page explains when each route fits, and why running both against the same work is a mistake.
Who can do what
Each part of this is unlocked by its own user actionUser actionA single protected capability, such as 'edit appointment', that a role can grant. The building block of role-based access control., and none of them requires the person to be a planner.
| User action | What it unlocks |
|---|---|
| Log own time | Tracking and claiming your own time, in My Work and the mobile app |
| View timesheets | The timesheets page, across all resources |
| Log time on behalf | Claiming, submitting and reopening time for another resource |
See roles and user actions for how they are assigned.
In this section
Time tracking
Track time on a task, turn it into a claim, and release it to the back office. The same on the web and on the phone.
Timesheets
Review the time logged across all resources, chase the gaps, and release it to the back office.
Setup
The connector, resource and permission configuration required before resources can log time and send it to the back office.