Skip to content
Timesheet Systems

All notes  /  01 · Requirements

What the Worker Can See

Accessibility of the record is part of the legal standard in several jurisdictions and a product capability that varies widely. What to require.

Reference

Where a duty to record working time exists, the record generally has to be accessible to the person it describes. Products treat this as a feature, and some do not have it.

What self-service should cover

Their own daily record: start, end, breaks, totals, for any retained period.

Cumulative hours against contracted, over the week, month and reference period.

Rest periods computed from actuals, with shortfalls visible.

Every edit to their record, by whom and when.

Their own project attribution.

Not: anyone else's data, and not a ranking against colleagues.

What it should not require

A request. Routine self-service, not a subject access process.

A manager's involvement.

A separate login to a system they otherwise never open.

A download in a format nobody can read.

Why it is worth requiring explicitly

It is part of the standard in jurisdictions that have implemented the recording duty, rather than a nicety.

It improves the data. People correct their own records when they can see them; nobody else has the knowledge to.

It reduces subject access requests, most of which ask for something the person should simply have been able to see.

And it makes the record credible. A figure the worker has seen and not disputed is worth considerably more in a dispute than one produced afterwards.

The dispute route

Separate from viewing, and it needs designing.

A way to flag an entry as wrong, with a response from a named person within a stated time.

The dispute logged with its outcome.

The original retained alongside any correction.

Review the log: a cluster around one team, one rule or one shift pattern is a configuration finding rather than a set of individual complaints.

Checking a product

Log in as an ordinary user during the trial, not as an administrator. The two views differ more than vendors mention.

Look at what a normal person can actually reach.

Try to see the edit history of your own record. Many products show only the current state to the subject while showing history to administrators, which is the wrong way round.

Try to export your own record.

Raise a dispute and see whether the workflow exists or whether the answer is to email someone.

On departure

An export at exit, as part of the process rather than on request.

Retention of the statutory record for the required period, which is a different decision from disabling the account and which products commonly conflate.

Access removed promptly, including any manager's view of the departed person's data.

Log in as an ordinary user

The trial step almost nobody takes.

Administrators see a different product from the one most people use.

Check what a normal person can actually reach: their record, their history, their edits, an export.

Try to see the edit history of your own record. Many products show only the current state to the subject and full history to administrators, which is the wrong way round.

Raise a dispute and find out whether a workflow exists or the answer is to email someone.

Why it improves the data

The argument that persuades people unmoved by the obligation.

People correct their own records when they can see them. Nobody else has the knowledge to.

It reduces subject access requests, most of which ask for something the person should have been able to see.

And a figure the worker has seen and not disputed is worth far more in a dispute than one produced afterwards — which makes self-access the employer's evidence as much as the worker's right.

Show people the relevant record

Remote workers need a clear view of captured time and the route for corrections. This implementation example can inform the test, but worker access should be verified directly with a non-admin account.