> For the complete documentation index, see [llms.txt](https://help.security.gallagher.com/knowledge-hub/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://help.security.gallagher.com/knowledge-hub/kenai-release-notes/2026/september/v5-1-2.md). # v5.1.2 **Date Released:** 18/09/2026 ### Custom sign-in form fields are generally available **Area:** Custom fields ยท Highlight The questions a customer adds to their visitor sign-in forms are **configured in the dashboard and generally available from this release**: a library of fields per location, a check-in form per visitor type composed from it, and conditions between the questions on a form. * **A library of fields**\ A field is defined once for the location: its label, its type, text, dropdown, multi-select or slider, with the choices or the range it offers, and on text and multi-select questions a helper text. A field's type is fixed once it exists. * **A check-in form per visitor type**\ Each visitor type's check-in form is composed from the library and ordered by drag. A field is asked only of the visitor types whose form includes it. * **Conditional fields**\ A field on a form is **shown or hidden** by an earlier question on the same form: by its answer, or by whether it was answered at all, matching any or all of its tests. A conditioned question can itself decide another, so conditions chain down the form. The kiosk, assisted check-in and the invite form all honour the condition. * **Retire and restore**\ A field no longer needed is retired rather than deleted. Answers already given to it stay readable, and the field can be restored to the library later. A question a notification names stays on the form and in the library, with its choices, until no notification names it. Learn more: [The visitor pre-registration flow](/knowledge-hub/kenai-user-guide/visitor-management/pre-registration.md), [Check in at the kiosk](/knowledge-hub/kenai-user-guide/visitor-management/kiosk-check-in.md), [Assisted check-in](/knowledge-hub/kenai-user-guide/visitor-management/assisted-check-in.md) ### Conditional notifications per visitor type **Area:** Notifications Each visitor type carries its own notifications, fired by a visitor's kiosk or pre-registration check-in, each with the conditions on the form's answers that fire it, who is told, and what they are sent, by email, by SMS, or both. * **Conditions on the answers**\ A notification carries one or more conditions on the form's answers: a choice on a dropdown or multi-select question, a slider at or beyond a number, or whether a text, dropdown or multi-select question was answered at all. It fires when any of them holds, or only when all of them hold, and several conditions may test the same question. Several notifications may share a condition; each fires on its own. * **Email**\ An email carries its own subject, title and copy, and goes to the visitor's host, to chosen addresses, or both. * **SMS**\ An SMS carries its own text and goes to the visitor's host, to chosen numbers, or both. * **When a notification sends**\ Each notification chooses the steps it sends on, pre-registration, sign-in, or both, with both on by default. A notification can also be paused: it keeps its words, its conditions and its place on every visitor type, and sends nothing until it is resumed. * **Retired notifications**\ A removed notification keeps its words and its triggers, stays with the visitor type that created it, and is restored there rather than authored again. Learn more: [Manage hosts and the host directory](/knowledge-hub/kenai-user-guide/visitor-management/hosts.md) ### Gallagher events **Area:** Integrations Integrations configuration extends from what an integration does on a visitor's journey to **what a card event at a Gallagher door does**: two server-side actions that run on the connector, and two events returned to Kenai. * **Remove presented card**\ The card presented at the door is removed from the cardholder when its type matches one of the selected card types. This is the reverse leg of the visitor badge linking available since v5.1.1: the badge is linked at sign-in and released at the door. * **Remove assigned card type**\ All the cardholder's cards of the selected card types are removed, whatever their expiry, with a filter to limit who it applies to. * **Sign-in on a card event**\ A card event at the selected doors and directions logs the visitor's sign-in in Kenai. * **Sign-out on a card event**\ A card event at the selected doors and directions logs the visitor's sign-out in Kenai. * **Only react when**\ Each event carries an optional filter on the cardholder's division, access groups or a personal data field, so a door reacts to the cardholders it should and no others. ### Rules on the Gallagher visitor events **Area:** Integrations The visitor events released in v5.1.1, what Kenai does in Gallagher on a visitor's journey, now **check each choice as it is made**. A pick the connector could never use is refused, with the reason shown. * **The PDF group holds data fields**\ A personal data field group with no data fields cannot be chosen. * **One group, one job**\ A group that grants access, or one already in use as an access-granting group, cannot be chosen as the PDF group, and the group chosen as the PDF group cannot be chosen as an access-granting group. * **Fields belong to the chosen group**\ Lookup fields, the photo field and the field mappings open only once a PDF group is chosen, and every field offered belongs to that group. * **Lookup fields are unique and of the right type**\ A lookup field must be flagged unique in Gallagher. The visitor's primary lookup takes a phone field and the secondary an email field. * **The photo field is an image**\ Only an image field can be chosen for the visitor's photo. * **Changing the PDF group keeps what overlaps**\ Choosing a different group keeps every lookup, photo field and field mapping the new group also holds, across the whole lane. Anything the new group lacks is named in one confirmation and cleared together, and the lane's events switch off only if the primary lookup goes. When nothing is lost the group switches without a dialog. * **A card slot takes its own credential class**\ The access pass and badge slots accept card-class credentials only, and the mobile credential slot accepts mobile-class credentials only. Any other class is refused with the reason. * **A lookup field is never also a field mapping**\ A field the visitor or employee lane looks cardholders up by is how the connector finds the cardholder again, so it cannot also receive a mapped Kenai value. The refusal names where the field is used as a lookup, on this event or on another. * **A door identity is a lookup field**\ A door event identifies its cardholder through a lookup field only. The identity row picks the visitor or employee type first, then offers only the fields that are a lookup somewhere on that lane. * **Nothing is attached twice**\ A door is attached with its direction chosen at the pick, Entry or Exit, and only a direction it does not already hold on the event. An access group, competency or card type already on the event is refused by the picker, and an attached item is swapped or refreshed in place rather than added again. * **Card type with numeric access passes off**\ While numeric access passes are switched off under credentials, only card types without a number range can be chosen. * **Card type with numeric access passes on**\ While numeric access passes are on, a card type can be chosen only if its number range matches the site's numeric range exactly; the range is quoted in the reason. ### One shared identity per lane **Area:** Integrations Changed: how the Gallagher integration finds and creates a cardholder is now **set once per lane**, on the all-visitors lane, instead of repeated on every event. * **Shared identity**\ The lane carries one identity block: division, PDF group, lookup fields, an optional photo field and the error recipients. Each event keeps only what is its own: whether it is active, the access groups, competencies and field mappings it grants. * **Events wait for the identity**\ Every event on the lane stays shut until the division, PDF group and primary lookup field are picked, and no event can be switched on before then. * **Visitor lookups are fixed**\ A visitor is found by mobile number first, with email as an optional second lookup. The customer picks only the Gallagher field for each; the Kenai side is fixed. * **Sign-out mirrors sign-in**\ Sign-out only ends what sign-in granted, so it carries its switch and nothing else. Removing sign-in removes sign-out, and sign-out cannot be switched on while sign-in is off. ### Host directory domain claim **Area:** Platform services An organisation claims its own email domains, and **who may create invites follows the claim**. * **Claimed by DNS verification**\ An administrator adds a domain and proves ownership with a DNS record; the dashboard shows the record to add and checks it on request. * **Invites follow the claim**\ Once a domain is claimed, hosts in the host directory on that domain can create invites. Before that, only hosts on the domain that came with the accounts order can. * **Authorised hosts only**\ Where the integration is configured for it, an invite leads to a pre-registration credential and from there to site access, so only hosts on claimed domains are allowed to create invites. * **All locations or chosen ones**\ A claimed domain applies to every location, current and future, or to the locations chosen for it. Learn more: [Manage hosts and the host directory](/knowledge-hub/kenai-user-guide/visitor-management/hosts.md) ### Custom iCal bot setup **Area:** Platform services An organisation registers its own forwarding or distribution-list addresses that relay calendar invites to the Kenai invite inbox, and decides how each is processed and where it applies. * **Register a forwarding address**\ A distribution list or mail rule on the customer's own mail infrastructure forwards invites to the Kenai inbox, and the address is registered in the dashboard. The page walks the administrator through the setup. * **Automatic or organiser-led**\ Invites forwarded from an address either create the visitor invites automatically from the organiser's saved defaults, or email the organiser a link to choose the location, host and guests and create them. * **All locations or one**\ An address applies to every location, current and future, or is bound to a single location. Learn more: [Invite from your calendar (iCal bot)](/knowledge-hub/kenai-user-guide/visitor-management/invites/ical-bot.md) ### Connector configuration extract **Area:** Platform services Two changes to the Gallagher configuration extract under the connector settings: **its progress now shows live**, and **running it no longer depends on the schedule**. * **Live status while an extract runs**\ New: the connector's configure extract panel shows an extract while it runs, whoever or whatever started it, and refreshes in place when it completes, with the result announced. * **Extract now, independent of the schedule**\ Changed: running an extract now needs only a connected connector. It no longer also needs scheduled extracts to be switched on, so a site can extract straight away, before its schedule is set up. ### Kiosk colours and a kiosk preview **Area:** Location details Two changes to Location Details: **the kiosk's text colour joins the brand colour**, and a kiosk preview shows the result as it is chosen. * **Brand colour and text colour**\ New: beside the brand colour, Location Details now sets the colour of the writing on the brand colour, Light or Dark, for a site and for a location, so a light brand colour no longer forces light text on light buttons. * **Preview kiosk app**\ New: a preview opens three kiosk screens beneath the colour fields, the welcome screen, the identity screen and the register screen, laid out as the device draws them, painted from the values as they are edited and carrying the location's own logo, so the effect of each colour is judged before it is published. Learn more: [Check in at the kiosk](/knowledge-hub/kenai-user-guide/visitor-management/kiosk-check-in.md) ### Directory origin **Area:** Platform services The host and employee directories now share one view of **where each record came from**, and what a directory sync does to it. * **Where a record came from**\ Every host and every employee shows its origin: Synced from the organisation's directory, Manual when created in the dashboard, or Edited when a synced record was changed in the dashboard. New: the employee directory shows this alongside the host directory, with the same filter and banner. * **Return to sync**\ An edited record can be returned to sync behind a confirmation that says what happens: the record is marked synced again, its details do not change right now, and the organisation's next directory sync replaces the edits. * **Synced phone numbers**\ Changed: a phone number arriving from a directory sync is stored in international format only, with the country code. A number in any other form is treated as no number. Learn more: [Manage hosts and the host directory](/knowledge-hub/kenai-user-guide/visitor-management/hosts.md) ### One sign-in experience **Area:** Sign-in The dashboard sign-in is modernised for Kenai users, recognises single sign-on domains, and **looks and behaves the same whichever way a user signs in**. * **A modernised Kenai login form**\ Users who sign in with a Kenai account get a redesigned login form: work email, then password, with a password reset by email. * **Single sign-on is recognised from the email**\ When the email belongs to a single sign-on domain, the form offers a button that takes the user to their organisation's sign-in. * **The same look and flow on both**\ The single sign-on pages are redesigned to the same language as the Kenai form, so a user sees one harmonised sign-in whichever path they take. ### Quality of life and reliability **Area:** Quality of life * **Configuration access follows every grant**\ A person granted configuration rights at a location or site sees its configuration area straight away, whichever location is selected in the dashboard. * **Invites follow the visitor's arrival**\ A visitor's sign-in marks every invite they hold for that day as arrived, stamped from their earliest arrival, not only the invite the sign-in came from. * **Directory access on dashboard grants**\ An administrator granted directory rights through the dashboard reaches the visitor and employee directories on that grant alone. * **Number ranges are inclusive**\ A numeric access-pass number range issues every number from its first to its last, both included, so adjacent ranges sit side by side. * **Live updates on busy sites**\ On a site with many sign-ins, live updates that arrive while a log is still loading are held and applied once it has loaded, in one pass. * **Reliability improvements**\ Employee log retrieval, the employee directory list, kiosk facial recognition, resource booking cancellations and host sign-out reminders. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://help.security.gallagher.com/knowledge-hub/kenai-release-notes/2026/september/v5-1-2.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.