Time tracking
A field resourceResourceAn entity that can carry out work - a person, vehicle, tool, or room - that you schedule on the planning board. is the only person who knows what their day actually looked like. The plan said two hours at the first site; the traffic, the missing part and the customer who wanted a word say otherwise. Time tracking is how that gets recorded where it happens, rather than reconstructed from memory on Friday afternoon. It works the same way in My Work on the web and in the mobile appMobile appThe companion app for field workers to see their schedule, update appointments and share GPS location from the field., and this page describes what both of them do.
It deals in the two records the overview introduces. 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 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. is the 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. you say you spent on a task on a given day. Folding the first into the second is called claiming, and it is a separate step on purpose.
Tracking time
You start a timer against a task and stop it when you are done. While a timer runs, the session has a start and no end yet.
You can only have one running session at a time. Starting a timer on a second task stops the first one, which matches how a person actually works: you are not in two places at once, and a forgotten timer should not quietly accumulate hours against a job you left this morning.
A session records what kind of time it was:
| Type | Use it for |
|---|---|
| Work | Time spent working on the task |
| Travel | Time spent travelling for the task |
| Waiting | Time spent waiting on the task |
Only work time becomes a claim. Travel and waiting are still recorded and still visible, but they do not turn into claimed hours on their own, so a day of driving does not quietly become a day of billable labour. If travel should be charged, it 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. that decides how, not the timer.
A session that runs past midnight is split at the day boundary, because a claim belongs to a single date.
Correcting a session
Timers get started late and stopped late. A session can be adjusted after the fact, and a session that was recorded entirely by hand is just as valid as one a timer produced.
The one thing you cannot do is silently reopen a finished session, and once a session has been folded into a claim it is locked. At that point the claim is the record that matters, and changing the evidence underneath it would put the two out of step.
Claiming
Both clients can tell you what your own sessions suggest you should be claiming: the finished work sessions you have not yet turned into a claim, grouped per task and per day. That list is the usual answer to "my timesheet looks too thin". Work that happened but was never claimed is invisible to everybody downstream.
Claiming folds those sessions into a claim for that task and day. A claim can be refused, in which case it tells you rather than failing quietly.
Claims can also be made directly, without a session behind them, for the work you did not run a timer on.
Releasing to the back office
A claim starts as a draft, which means it is yours and still editable. Nothing has been sent.
Releasing it hands it to the back office, and from that point it is no longer editable. Whether it is approved is decided there, not here. What can come back is a reason: either the hand-off never landed, or somebody in the back office refused the entry. Neither is something to re-enter from scratch. Read the reason, fix what it names, and release again. The full lifecycle, and what each status means, is on the timesheets page.
What you can see
You see your own time, not the team's. Sessions, claims and the tasks available to claim against are all scoped to the resource you are signed in as.
Times are recorded on your own clock. A session that started at 08:05 for you reads 08:05 to everyone looking at it, with no time zone conversion applied on the way. This is deliberate: a technician's morning should not shift because a server or a planner sits in another time zone.
Permissions
Time tracking needs the Log own time user actionUser actionA single protected capability, such as 'edit appointment', that a role can grant. The building block of role-based access control.. Updating the progress of your own tasks needs Progress own tasks. If neither appears, ask your administrator to grant them. See roles and user actions.
A team lead reviewing everybody's time works from the timesheets page in the web app, which needs different permissions again.
Related
- My Work - the timer and the weekly grid in the web app.
- Mobile app - the same timer, on the phone.
- Timesheets - the oversight view across all resources.
- Time registration API - the entities and their contract.