Skip to content
Timesheet Systems

All notes  /  04 · Integrations

Identity and Access

Who can sign in, who can see whose record, and what happens when someone leaves. The joiner-mover-leaver path is where this goes wrong.

Procedure

A timesheet system holds a record of every employee's working day. Access to it deserves the same attention as any system holding personnel data, and usually gets less.

Single sign-on

Worth insisting on for anything above a small deployment: one account lifecycle, one place to disable someone.

Check which protocol, and whether it is included or an upgrade tier. Charging extra for the security feature is common and worth naming during negotiation.

Check whether provisioning is included or only authentication. Sign-on without provisioning means accounts are still created and disabled by hand.

Check the break-glass path. If the identity provider is down, can an administrator still get in to fix a payroll run? A product with no answer has one anyway, and it is usually a shared local account.

Joiner, mover, leaver

Joiner: an account before the first shift, not after. A new starter unable to record their first week generates a retrospective entry, which is the least accurate kind.

Mover: a change of team, pay group or manager changes who approves and who can see. Products vary in whether this is retrospective — does the new manager see the old records?

Leaver: access removed promptly. And the record retained for the statutory period, which is a different decision from the account.

The leaver case is where most audits find problems, because disabling the account and retaining the data pull in opposite directions and products often conflate them.

Roles worth separating

Record own time. Everyone.

Approve for a team. Managers, scoped to their own team.

Administer configuration: rules, rates, projects.

Run payroll export.

View reports, which should not automatically include individual detail.

Audit access, read-only, for whoever reviews.

Products commonly ship three roles and expect you to fit. Ask whether roles are definable, and whether scope can be limited to a team rather than the organisation.

What managers should see by default

Their own team, as exceptions and aggregates.

Not everyone's daily start and finish times, routinely.

Individual detail behind an action that records why.

This is a configuration choice and most products default the other way, which means it is a decision someone makes or fails to make.

Testing it

Create, move and disable a test person through the identity provider and watch what the timesheet system does at each step.

Check whether a disabled person's historical records remain and remain attributable.

Check whether a former manager retains visibility of their old team.

Pull the access log and see whether it records reads as well as writes. Many record only writes, which means you cannot answer who looked at someone's record.

The break-glass path

A question every product answers, whether or not it has been designed.

If the identity provider is down, can an administrator still get in to fix a payroll run?

A product with no designed answer has one anyway, and it is usually a shared local account that nobody rotates.

Require a named emergency account, with its use logged and alerted.

Test it once, during implementation, and record that you did.

Identity and recorded activity

Authentication proves who accessed the service, while employee PC activity tracking creates a separate operational record. Permissions, retention and review rights must cover both.