Access

Work Locations and Biometric Devices are part of the Time & Attendance module. Configuration requires manage_attendance_config, separately from timesheet management. Clock/attendance users have narrower access to active locations and the geofence setting needed by the clock flow.

Work locations

Set up a workplace

Open Work Locations and create the site employees will clock in from.
Enter its coordinates (or click Use Current Location) and a radius from 50 to 50,000 metres, 200 by default. Set the Timezone to Company default or a specific zone: it decides which calendar day and shift a punch belongs to. Use the actual clocking area, rather than an unrelated postal-address point, when choosing the centre.
Use the Team Scope select to choose All Teams or one team. Check that the intended employees belong to those teams.
Review the location's enforcement setting and the company enforcement toggle described below before asking staff to use it.
Try a clock-in from the intended area and review the recorded location and date. A location configured on a map is not evidence that a particular phone can obtain a fix there.

To fill in the coordinates from Google Maps, paste a link into Google Maps link or coordinates on the form and click Fill in. In Google Maps, press and hold the exact spot to drop a pin, then tap Share and copy the link. Coordinates such as -1.2864, 36.8172 work too, and are the surest way: they appear at the top when you drop the pin. The link must point to an exact spot. A place shared by its name may not carry one; if Arche says the link has no exact point, drop a pin instead. Check on Google Maps, beside Use Current Location, opens the point in a new tab so you can confirm it is the right place.

Create a location with a name, coordinates and radius; address and Team Scope are optional. A location set to All Teams applies to employees across teams. Team locations apply through the employee's team membership or direct team assignment. Only active locations are considered.

The company Geofence Enforcement toggle and the location's Enforce geofence setting work together:

Company enforcement off: locations can still supply a coordinate/timezone match, but do not restrict clock-in.
No active enforced locations anywhere in the company: there is nothing to enforce yet.
Enforcement on, with enforced locations configured, but none applicable to the employee: clock-in is rejected.
Applicable locations exist but are informational only: the employee's clock-in is unrestricted.
Applicable enforced locations exist: valid coordinates must fall within at least one enforced radius for clock-in.

Distances use the haversine calculation. Coordinates are checked for valid ranges and missing values. A matching work location can determine the entry's calendar timezone, with company timezone fallback.

What a punch stores

Arche keeps the coordinates of a web or mobile punch only when it uses them:

A clock-in keeps them when they fall inside a work location that applies to the employee. That location decides the entry's calendar day, and a later correction reads the coordinates again to find it.
A clock-out keeps them when geofence enforcement applies to the employee. They are the evidence behind the check and any [Geofence] note.

In every other case the entry holds its clock times without coordinates. A company with no active work locations stores none. Entries recorded before October 16, 2026 keep the coordinates they already have.

Clock-out differs from clock-in

The backend lets an existing open entry close even if location is missing or outside the fence. It records a [Geofence] note for review instead of leaving the entry open. A geofence exception prevents automatic approval.

The web and mobile apps follow these rules rather than their own. They send your location whenever they can read it and never stop a clock-in or clock-out for want of one, so the rules above decide every time: a clock-in that needed a location is refused with a message saying what to fix, and a clock-out is never stopped for it. The mobile app discards device-reported mocked fixes and tells you so, and accepts a cached fix no older than 60 seconds with accuracy within 250 metres when live attempts fail. These checks do not establish that every spoofed location will be detected.

See Time & Attendance for corrections and approval.

Departure alerts

A location can also tell a manager when someone leaves during a shift. Turn on Tell a manager when someone leaves during a shift on the location and set Minutes away before an alert (2 to 120, 10 by default). This works apart from geofence enforcement.

How it works:

When someone clocks in with the Arche phone app inside a location that has departure alerts, the app asks once for location in the background ("Allow all the time"). If their shift is scheduled at that location, that one is watched; otherwise the nearest such location around the clock-in.
While they stay clocked in, the phone reports when they leave the location and when they come back. Arche stores only those times, never a position, and deletes them after 180 days.
If they are still outside when the minutes run out, and still clocked in, Arche tells them and their direct manager. When the direct manager cannot manage attendance, it tells people who hold both manage_attendance and view_all_attendance. Managers of other teams are not told.
Watching stops at clock-out, at sign-out, or when the location turns alerts off.

Anyone with view_attendance or manage_attendance sees every report on the Departures tab of Time & Attendance > Attendance: who left, from where, when they came back and whether an alert went out. The list shows only people in your reach.

Treat an alert as a prompt to check, not as proof. A phone can report late, lose a report with no signal, or not report at all when location in the background is off. A radius of 150 m or more gives fewer false alerts. An alert never changes hours, pay or approval. The watch runs only on a phone with the Arche app: after a clock-in on the web inside such a location, it starts the next time the person opens the Arche app. If background location is not yet allowed, they open Time & Attendance and tap the departure alert line to allow it.

Registering biometric devices

The page has Devices, Enrollments and Sync Logs tabs. Register a name, company-unique serial number and device type. The current types are Generic, ZKTeco and HikVision. Optional device details include model, location, work-location association and IP address. A work-location association supplies timezone context for punches.

Device keys are shown once on creation or regeneration. Only a hash is stored, and normal device reads do not return it. Regenerating changes the key accepted by key-authenticated ingress.

Ingestion paths

Device integration	Endpoint and authentication
Generic REST	`POST /api/biometric/webhook/push` using `X-Api-Key`
Hikvision events	`POST /api/biometric/webhook/hikvision/:deviceKey`; the device key is part of the URL
ZKTeco ADMS	Root `/iclock/getrequest`, `/iclock/cdata`, `/iclock/devicecmd` and `/iclock/ping` routes; serial-based registration with explicit ADMS opt-in (see below)

ADMS serial numbers are identifiers, not secrets. Authentication also checks the registered source IP when supplied and rejects ambiguous serials across companies. The device must be active and its company licensed. Do not assume ADMS has the same authentication strength as a per-device secret. The ADMS opt-in is the checkbox Allow direct ZKTeco push (ADMS), which appears when you edit a device, not when you register it. Set the IP address as well, so only that address is accepted. The Direct push column shows whether a device is IP bound or serial only. The page shows the generic webhook address and, after you register a device, the key to send in the X-Api-Key header. For ZKTeco ADMS and Hikvision, use the endpoints in the table above and your reader's own manual, and confirm real punches in Sync Logs.

Native Hikvision processing accepts supported event JSON, including its multipart event field, and does not retain accompanying face images. Native protocols feed the same attendance integration as the generic webhook. Code support is not certification of every hardware model or firmware version.

If an active reader that has synced before sends nothing for over 24 hours, people with manage_attendance_config get an alert, once each time it goes silent. See Alerts & Notifications.

Enrollment mappings

Connect a reader to employee records

Register the reader in Devices, selecting the correct integration type and work location.
Copy the key when shown. The generic webhook takes it in the X-Api-Key header. For ZKTeco ADMS and Hikvision, use the endpoints in the table above and your reader's own manual. Treat a key-bearing URL like a credential.
Open Enrollments and map the reader's badge/enrollment identifier to the correct employee.
Submit a test punch from the reader and check Sync Logs, then check the employee's time entry.
Test clock-out as well as clock-in before relying on the reader for attendance.

Arche's employee mapping is separate from enrolling a person on the physical reader. Use the reader's own enrollment procedure to obtain the identifier you map here.

Map the badge/enrollment ID to an employee. Mappings can be device-specific or company-wide. Resolution prefers the device mapping, then the company-wide fallback. This allows identical badge numbers on different readers to identify different employees without a company-wide collision.

A missing mapping is a processing problem to resolve in Enrollments. Reprocess eligible failed log rows after correcting the mapping.

Punch processing and review

The integration logs accepted punches and applies timestamp, replay and duplicate-punch checks before creating or updating attendance. Direction can be in, out or unknown; unknown punches use the current entry state. Overnight and split-shift matching are supported, and questionable sessions can require correction instead of receiving guessed working hours.

Use Sync Logs to inspect processing status and errors. Not every raw network request becomes a punch log: authentication failures and vendor records that cannot be translated are rejected or skipped earlier. Check the configured reader, event shape, device status, work-location timezone and enrollment mapping when a punch is absent.

Employees can submit their account of missing or incorrect time through the correction workflow. A manager reviews it before attendance changes; see Time & Attendance.

Troubleshooting

Symptom	What to check
Clock-in says no location is available	Phone location permission and service, then the employee's applicable enforced locations
An employee at the site is outside the radius	Site coordinates/radius and the phone's reported position
A reader punch has no employee	Badge identifier and device-specific/company-wide enrollment mapping
A punch appears on the wrong calendar date	Reader timestamp and associated work-location timezone
Nothing appears in Sync Logs	Reader endpoint, authentication, active device state and supported event format
A log has failed after a mapping error	Correct the mapping, then reprocess the eligible failed log

Do not invent an employee's working hours to make a failed punch disappear. Use the correction workflow to record the actual span and reason when attendance needs review.

Work Locations, Geofencing & Biometric Devices