Idle time tracking decided on the server, not by a timer in a browser tab

Idle auto-pause is a setting in AMS with one switch — Pause timers on inactivity — and one number: how many minutes count as inactive, from 5 to 240, with presets at 5, 10, 15, 30 and 60. When the switch is off, a timer runs until the person pauses or checks out themselves. When it is on, a timer that has seen no activity for longer than the threshold is paused, and the pause is backdated to when the inactivity began, so the idle minutes never reach the timesheet.

Activity in any Orbiz tool counts — working in Cadence keeps the AMS clock running — and so does watching a recording. Changing the policy is a permission you grant to a role, like every other setting in Orbiz.

Most idle detection is a timer inside a page: no mouse movement for so many minutes, so the page decides you left. That fails in predictable ways. Browsers slow down the timers of a hidden tab, a laptop that went to sleep looks like a person who walked away, and two open tabs can disagree about whether you are working at all.

In Orbiz the browser is a sensor, not a judge. One tab per device sends a heartbeat every 30 seconds while a timer runs, saying how long ago there was input, whether the operating system reports the computer idle or the screen locked, whether a recording is playing and whether an Orbiz window is in front. It sends timings and yes-or-no flags, never what was typed. The server merges that evidence across all of the person’s devices, applies the organisation’s one threshold and answers with whether the timer is still running. When it pauses one, every Orbiz tool the person has open shows the same dialog within seconds.

Browsers differ in what they can see outside their own window, and AMS says so on the policy page instead of hiding it.

• Chrome and Edge, with permission granted: the operating system reports keyboard and mouse activity from any application, and screen lock. Typing in an IDE or Slack keeps the timer running. Members are asked for the permission at check-in.
• Safari, Firefox and Brave: they cannot see activity outside the browser, so a timer pauses only on unambiguous evidence — the browser going away for 45 minutes, or the screen locking. Working in another application never pauses it.

The pause dialog names the rule that fired and the time the inactivity began, on the person’s own clock. “No activity for 16 minutes” on its own reads like a claim about this moment; naming the hour makes a right pause obviously right and a wrong one easy to argue. The reasons it can give are: the screen was locked; the computer saw no keyboard or mouse activity; Orbiz was open in front with no activity; or the browser stopped reporting. When the browser itself said why it went quiet — it shut the page down to free memory, or froze it in the background — the dialog gives that reason instead.

A false pause should cost one click, not a correction request. The dialog offers I was still working for an hour after the pause — twelve hours when the pause came from a browser that stopped reporting, since nobody was at the screen to see a shorter offer. Undoing reopens the exact segment the pause closed, so the time is continuous again and the running clock shows it straight away, not only the stored timesheet.

An admin can turn the undo off. After that, or once the window has closed, a wrong pause is repaired by an approver: the timesheet entry lists every pause holding time back from that day, with its reason and minutes, and an approver restores it with Restore time. Editing the check-in or check-out does not give that time back — restoring the pause does — and a member looking at the entry is told to ask an approver rather than left to guess. While a timer is paused, screenshot capture pauses with it.