Worklog / Guide
Work-record field guide

Decide what a time record should contain.

Define purpose, access and exclusions before enabling automatic activity tracking. A practical worksheet for a transparent small-team rollout.

Start with the minimum record that answers the stated question. A duration requirement alone does not establish a need for screenshots, document titles or browsing history.

Explore this collection →

Documentation reviewed · 23 Sep 2026No hands-on merchant testing

Name a recipient and a decision

Replace “we need visibility” with a concrete sentence: our project coordinator needs accepted duration by project for the week. That statement suggests a project identifier, date range, duration unit and review state. It does not yet justify capturing the content of a person’s screen. Ask the recipient what action each additional field would change. If there is no answer, leave that field out of the initial specification.

Separate four kinds of information

A duration says how much time was recorded. A timestamp says when a record began or ended. Activity describes interaction with a device. Work output describes what was produced. These categories may relate, but they are not interchangeable. A phone call or an offline meeting can involve work without keyboard activity. Do not use an idle label as an automatic deduction or a judgment about a person.

Scroll horizontally to compare every column.

Field familyQuestion it can help answerWhat it does not prove
DurationHow much time was recorded?Entitlement to pay or client billing
Start/end timestampWhen did this record occur?Which timezone was intended unless recorded
Device activityWas there device interaction?Whether all work was captured
Review stateHas someone reviewed this version?That the next export contains that version

Test the privacy boundary as a user

DeskTime documents a Private time mode that pauses activity tracking, but administrators can restrict availability. Treat that as a configuration to demonstrate, not an unconditional guarantee. Use fictional material when checking the intended account. Show the team where tracking starts and stops, what is visible to each role and how a concern can be raised. Confirm the behavior again after changing settings.

Write the rollout note before installing

A useful note states purpose, included fields, excluded fields, who can see records, how corrections work and who owns unresolved questions. Give it to the people affected before rollout. If the organization has not resolved its authorization or applicable obligations, stop at the specification stage. This guide is an operational design aid; it does not establish legal compliance or replace jurisdiction-specific advice.

Put this check into the wider workflow

Continue with the specific decision your record still needs.

Sources and boundaries

Primary documentation supports the dated product facts. Proposed checks and fictional examples are our editorial method, not observed product results.