Timesheets
The Timesheets page is where somebody responsible for a team looks at logged time across every resourceResourceAn entity that can carry out work - a person, vehicle, tool, or room - that you schedule on the planning board. at once: what was logged, what is missing, and what is stuck on its way to 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.. It is the reviewing half of time in Dime.Scheduler. The recording half, the timer and the weekly grid a resource works in, is on the time tracking page.
The page has three tabs. Overview is the summary, Entries lists what was logged and where each entry stands, and Tracked time is what the timers recorded. The period picker at the top right sets the week or range all three report on.
The page needs the View timesheets user actionUser actionA single protected capability, such as 'edit appointment', that a role can grant. The building block of role-based access control.. Log time on behalf additionally allows acting for a resource: adding their tracked time to a timesheet, submitting it and reopening it on their behalf, which is what lets you fix somebody else's week rather than only look at it. See roles and user actions.
Tracked but never claimed
Two records lie behind this page: 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 what a timer observed, 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 what a resource claims, and only entries reach the back office. The overview explains why they are kept apart.
The gap between the two is the interesting part. Work that was tracked but never claimed is the usual explanation for a timesheet that looks too thin, and this page is built to surface exactly that. The Tracked time tab lists the sessions, each marked whether it has made it onto a timesheet, and Not on a timesheet narrows the list to the ones that have not. Add to timesheet for resource claims the selected ones on the resource's behalf.
Sessions that never made it onto a timesheet
Only work sessions count toward a claimClaimThe 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., so travel and waiting time show up here without quietly inflating a billable total.
Reading the week
The Overview tab answers the question a team lead actually has: has everybody logged what they were expected to log, or are there holes. Its tiles say how much was logged, how much of that has been submitted, how many scheduled resources have no timesheet at all, how many submissions failed, what is waiting on approval in the back office, and the billable share. Below them, logged time is broken down per day, split between what is still with the doer and what has been submitted, and per project. The Coverage table at the bottom lists every scheduled resource with their scheduled, logged and submitted hours, badged with the entries that never arrived or were refused.
The timesheets overview
A thin week usually has one of three causes, and they are worth distinguishing before chasing anybody:
- The work was tracked but never claimed. Look at the unclaimed sessions.
- The work was never tracked at all. That is a conversation, not a data problem.
- The entry exists but failed on its way to the back office. Check the status.
The Tracked time block at the foot of the overview is where the first cause shows up. It splits what the timers recorded into work, travel and waiting, and counts the tracked work that never reached a timesheet. Two further counters catch entries that have drifted from their evidence: diverged entries, where somebody typed hours over the measurement, and unbacked entries, built from tracked time that has since changed or gone.
Status, and what it means for you
An entry moves through a short lifecycle on its way out of Dime.Scheduler.
| Status | What it means |
|---|---|
| Draft | Still editable by the resource. Nothing has been sent. |
| Submitting | Released, waiting for the back office to acknowledge it. |
| In back office | The back office has it and it is locked, waiting for someone there to approve it. |
| Approved | Approved in the back office. Nothing more is owed. |
| Not sent | The hand-off failed and the entry never reached the back office. The reason is on the entry. |
| Rejected | Somebody in the back office refused it. The reason is on the entry. |
An integration sees the same six states under their API names: Draft, Submitting, Accepted (shown here as In back office), Failed (Not sent), Approved and Rejected. The values and the moves between them are on the time API page.
Not sent and Rejected are the two to watch, and they mean different things. Not sent means the hand-off itself did not land, and retrying is often all it takes. Rejected means the entry landed and a person in the back office refused it, usually because the task or the job it points at is not in a state they will accept. The message travels back with the entry either way, so you can see why rather than guess, fix the cause and release again.
An entry that is in the back office but not yet approved can be handed back to the resource as a draft with Reopen for resource, for the case where something turns out to be wrong before anybody there has signed it off. An approved entry cannot.
The Entries tab is where you work through this. It lists every entry with its status and, for a failed one, the message that came back. Filter by status, switch between a flat grid and a grouping by project or by resource, retry the failed ones in one go, or export the lot to Excel.
The entries tab with two failed submissions
How an entry reaches the back office
Releasing an entry does not write to the back office directly. The entry moves to Submitting and is queued for the connectorConnectorAn integration that links Dime.Scheduler to a back-office system, routing data in and scheduling decisions back out., which picks it up and registers it. The entry then waits in that state until the connector says what happened: In back office once it has been accepted there, Not sent with a reason if it never arrived.
Whether the connector creates a new record or updates an existing one depends on whether the entry already carries a back-office reference, so re-releasing a corrected entry updates the original rather than double-registering it.
Two failures happen before the entry ever leaves Dime.Scheduler, and they look the same on screen but have different fixes:
- The resource has no 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.. Nothing can be registered against a resource the back office cannot identify. Fix the resource record, then release again.
- The queue could not be reached. A transient outage. Dime.Scheduler retries, and once it is clear the queue is down it stops retrying every remaining entry so a whole week fails quickly rather than slowly. Release again once the connection is back.
Both mark the entry Not sent and put the reason on it, which is why the message on such an entry is worth reading before assuming the back office rejected the hours.
What this page does not do
It does not approve time. Releasing an entry hands it to the back office, and the back office decides whether to accept it. That boundary is deliberate: approval carries a financial consequence and belongs in the system that owns costing, not in the scheduling tool.
Related
- My Work - where a resource logs the time this page reviews, from the browser.
- Time tracking - how a resource records time, on the web and on the phone.
- Time registration API - the entities and their contract.
- Time registration MCP tools - reading logged time and sessions with AI.
- Projects - the Time tab of a project shows the same data for one project.