Skip to main content
A biometric terminal does not know your employees. It knows numbers — the user ID assigned when a finger or face was enrolled on the device. Mapping is how those numbers become people.

​
How OnTime resolves a punch

When a punch arrives, OnTime tries three things in order:
1

An explicit mapping

A terminal user mapping you created. Always wins.
2

An exact employee code match

The terminal’s user ID equals an employee’s code exactly.
3

A unique numeric-suffix match

The terminal’s user ID matches the numeric part of exactly one employee code — EMP-0047 resolves from terminal user 47.
Ambiguity parks; it never guesses. If two employees’ codes both end in 47, the punch is parked rather than attributed to either. That is the correct behaviour and the reason to create explicit mappings rather than relying on the convention.
If none of the three resolves, the punch parks.

​
Parked punches

A parked punch is held, not discarded. It is recorded with the terminal’s user ID, the device and the timestamp, and marked unmapped. No punch is ever dropped.
This is the single most common terminal question — “the punches aren’t appearing” — and the answer is almost always that they are parked.

​
Creating a mapping

1

Open the unclaimed queue

Attendance → Devices → Unclaimed users. The tab carries a count, so a non-empty queue is visible without opening it. Each row shows the terminal user ID, which machines it has been seen on, when it was last seen, and how many punches are waiting behind it.
2

Identify the person

The machines a number has been seen on usually narrow it down on their own. Beyond that, the terminal’s own enrolment records — which OnTime records as they happen — tell you which number was assigned to whom.
3

Map it

Link the terminal user ID to the OnTime employee.
A number that already resolves by the employee-code convention appears here as a guess, with that employee preselected — confirming it takes one click and turns the convention into an explicit mapping.
4

Watch the parked punches replay

Mapping replays everything automatically. Every parked punch for that terminal user is applied, and each affected day is re-reconciled. There is no separate replay action and nothing to trigger.
The queue shows only what still needs a decision — numbers with no confirmed employee, plus unconfirmed code-convention guesses. Once a number is mapped it leaves the queue and appears on that employee’s own Devices tab, alongside the machines they have punched on. That is where to look up or remove an existing enrolment.

​
Removing a mapping

Deleting a mapping stops future punches for that terminal user resolving to that employee.
It does not un-apply punches that have already been applied. Those are real attendance events on real day records. If a mapping was wrong and punches landed on the wrong person, they have to be corrected as attendance — see Manual punches and overrides.Check a mapping before you create it, not after.

​
Enrolment is still a physical step

Mapping is a database link, not a hardware sync. It tells OnTime who terminal user 47 is; it does not push or pull fingerprint templates.Enrolling someone’s finger or face happens at the device, in person. Mapping is what you do afterwards.

​
Keeping mappings healthy

1

Map before go-live, not after

Clearing the unmapped queue is on the go-live checklist for a reason. Parked punches are recoverable, but a month of them is a bad first week.
2

Map new joiners as part of onboarding

Enrol on the device, then map. Two steps, same day.
3

Check the queue after replacing hardware

A new device may number its enrolments differently.
4

Prefer explicit mappings over the code convention

Suffix matching is a convenience that stops working the moment two codes collide.