Summary
The First Person In (FPI) rule keeps a door unlocked for the rest of a schedule window once the first authorized person badges in successfully at that specific door. This article explains what triggers FPI, how to limit who can trigger it, and an important limitation on Mercury hardware.
What First Person In does
When FPI is enabled on a door with an unlock schedule, the door stays in a locked/secure state at the start of the schedule and only switches to unlocked after the first successful badge-in on that door during the schedule window. It remains unlocked until the schedule ends. The badge-in must happen at that specific door — a grant at another door does not trigger it.
Who can trigger it by default
By default, any user who has access to that door during the schedule can be the "first person in." FPI does not, on its own, distinguish between groups.
How to restrict who can trigger it
Who is allowed to trigger FPI is controlled by the user's Authority Level, and Authority Levels are assigned per user, on each user's profile, at the Location level. To limit triggering to a specific set of people:
Go to the user's profile.
Under the relevant Location, set the appropriate Authority Level.
Repeat for each user who should be able to trigger the unlock.
Important limitation (please set expectations honestly)
On Mercury hardware, there is currently no way to assign an Authority Level, or FPI trigger eligibility, to an access group or user group — and there is no access-group dropdown on the First Person In rule. Older documentation and some screenshots show an access-group selector; that control is not available on Mercury. Triggering can only be scoped per individual user via Authority Levels.
This means a setup like "several groups can open Door 1, but only Group A should trigger the hold-open" cannot be configured at the group level today. It requires assigning the Authority Level to each qualifying user individually.
If per-user assignment isn't practical
If you have a large number of users and per-user assignment isn't feasible, do not attempt a workaround that won't hold. Instead, contact Genea Support — the team can request a back-end bulk Authority Level assignment if you provide the list of users or the access group(s) involved. This is a manual, support-assisted operation, not a self-serve setting.
Known limitation / feature request
Group-level First Person In triggering is a recognized product gap and an open feature request. If a customer needs it, acknowledge it is not currently supported, offer the per-user or support-assisted bulk options above, and route the request to the team rather than describing a UI control that isn't present.