> ## Documentation Index
> Fetch the complete documentation index at: https://docs.ontime.hosai.app/llms.txt
> Use this file to discover all available pages before exploring further.

# Map terminal users to employees

> Link a terminal's numeric user ID to an OnTime employee, and replay the punches that were parked waiting for it.

export const PermissionNote = ({perm}) => <Info>
    Requires the <code>{perm}</code> permission. Ask your administrator if an
    action described here is missing from your screen — see
    [Roles & permissions](/help/concepts/roles-and-permissions).
  </Info>;

<PermissionNote perm="device:write" />

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:

<Steps>
  <Step title="An explicit mapping">
    A terminal user mapping you created. Always wins.
  </Step>

  <Step title="An exact employee code match">
    The terminal's user ID equals an employee's code exactly.
  </Step>

  <Step title="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`.

    <Warning>
      **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.
    </Warning>
  </Step>
</Steps>

If none of the three resolves, the punch **parks**.

## Parked punches

<Warning>
  **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.
</Warning>

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

<Steps>
  <Step title="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.
  </Step>

  <Step title="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.
  </Step>

  <Step title="Map it">
    Link the terminal user ID to the OnTime employee.

    <Tip>
      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.
    </Tip>
  </Step>

  <Step title="Watch the parked punches replay">
    <Note>
      **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.
    </Note>
  </Step>
</Steps>

<Note>
  **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.
</Note>

## Removing a mapping

Deleting a mapping stops future punches for that terminal user resolving to that employee.

<Warning>
  **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](/help/attendance/manual-punches-and-overrides).

  Check a mapping before you create it, not after.
</Warning>

## Enrolment is still a physical step

<Note>
  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.
</Note>

## Keeping mappings healthy

<Steps>
  <Step title="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.
  </Step>

  <Step title="Map new joiners as part of onboarding">
    Enrol on the device, then map. Two steps, same day.
  </Step>

  <Step title="Check the queue after replacing hardware">
    A new device may number its enrolments differently.
  </Step>

  <Step title="Prefer explicit mappings over the code convention">
    Suffix matching is a convenience that stops working the moment two codes collide.
  </Step>
</Steps>