Validation

Validation decides which identity-document numbers the system accepts, when two people are treated as the same person, and whether an expired scanned document may be used. It is one main panel with three sections, a second panel for visitor duplicates and a third panel for staff and personnel duplicates, and everything on it applies system-wide - to the admin screens, to public self-registration, to group member capture and to the kiosk.

Before you start: you need settings administration rights. Decide first which documents your visitors and staff actually present: an identity card, a passport, a driver’s licence, a works number. Every rule you leave unticked is a document format your operators will not be able to capture.

Step 1: Open Validation

In the left sidebar open Configuration, click System Settings, then click Validation under Localisation.

Validation in the System Settings sidebar

Click Save at the bottom of the panel to apply your changes, or Cancel to discard them. Nothing takes effect until you save.

How a document number is checked

Before the individual settings, the rule that ties them together:

The enabled validation types are combined with OR. A number is accepted if it satisfies any one of the ticked rules. Ticking more types makes the check more permissive, not stricter.
A blank field is always accepted here. Whether a field must be filled in at all is a separate decision, made by the required-fields settings for each capture channel. Validation only judges the content of a value that was supplied.
If you untick every type, the system falls back to Basic Alphanumeric so capture never breaks completely.
When a value is rejected, the operator or visitor sees “The identity document number you entered is not valid. Please check it and try again.” under the identity field and the form is redisplayed with everything else they typed intact. Nothing is saved until the value passes.
The same rules apply to the Identity Number field on visitor, personnel and user forms, and on the staff self-registration link. The personnel Passport Number field is the one exception: it is always checked as a passport.

Allowed Validation Types

Check for Spam/Bruteforce Patterns rejects obvious junk before any other rule is applied: runs of one repeated digit (1111111), straight sequences (1234567, 7654321), and similar throwaway values. It is a filter on top of the other types, not a type of its own, so a value it rejects cannot be rescued by any other tick.

Turn it on for public self-registration, where visitors who do not want to give a real number type a placeholder. Turn it off if your organisation issues genuinely sequential works numbers that the filter would refuse.

The Check for Spam/Bruteforce Patterns option

Basic Alphanumeric accepts any combination of letters and digits between 6 and 20 characters. It is the default, and it is the right choice when your visitors present a mix of documents you cannot predict. The trade-off is that it catches almost nothing: a typo of the right length passes.

The Basic Alphanumeric option

Basic Alphanumeric (with dashes) is the same 6 to 20 character rule but also permits dashes, for documents whose numbers are printed with separators. Enable it alongside, or instead of, Basic Alphanumeric when operators would otherwise have to strip the dashes by hand.

The Basic Alphanumeric with dashes option

South African ID Number requires 13 digits that pass the South African checksum. This is the one rule with a special interaction worth knowing: when it is enabled, a 13-digit value must pass the checksum even if Basic Alphanumeric is also ticked. Without that rule a mistyped identity number would slip through on the permissive rule; with it, a transposed digit is caught at capture. Values that are not 13 digits (passports, staff numbers) are unaffected and still benefit from the other ticked rules.

The South African ID Number option

US Social Security Number applies the 9-digit US issuing rules. Enable it only where SSNs are genuinely presented; collecting them where they are not needed is a data-protection liability.

The US Social Security Number option

Generic Passport Format accepts a country-neutral passport number of 6 to 20 alphanumeric characters. This is the practical choice for a site that receives international visitors: it accepts every real passport without you having to predict which countries turn up.

The Generic Passport Format option

Country-Specific Passport Validation replaces that generic rule with per-country format rules and reveals the Allowed Passport Countries panel below. It is stricter and it will reject a valid passport from any country you did not tick, so use it only where you control who visits. If you enable it and tick no countries at all, the country rule contributes nothing and the panel is not saved as valid.

The Country-Specific Passport Validation option

Current validation is a live line of text under the options that restates the rules your ticks add up to. Read it after every change: it is the quickest confirmation that you enabled what you meant to. A warning also appears here if you have unticked everything.

The Current validation summary

Allowed Passport Countries

This panel appears only while Country-Specific Passport Validation is ticked. Passports from countries that are not ticked are rejected.

The Allowed Passport Countries panel

The shortcut buttons operate on the whole list: Select All ticks every country, Deselect All clears them, and Select Major Countries ticks the eleven largest-traffic countries so you can start from a sensible set and prune it.

The Select All, Deselect All and Select Major Countries buttons

The list itself covers South Africa, United States, United Kingdom, Canada, Australia, Germany, France, India, China, Brazil, Japan, Italy, Spain, Netherlands, Sweden, Norway, Denmark and Finland. Tick every country whose passports your reception genuinely sees; an unticked country means a real visitor standing at the counter cannot be captured.

The country list

Validation Preview

The preview panel restates, in plain language, every format currently accepted and shows a worked example of each. It updates as you tick and untick, before you save.

Use it as the acceptance test for this page: if a format your operators handle every day is not listed here, they will not be able to capture it after you save.

The Validation Preview panel

Scanned Document Validation

Reject expired scanned documents is on by default. When a document is read by an identity-card reader or by document scanning, its expiry date is checked: if the document expired more than the grace period ago, the scan is refused and none of the scanned details are used to fill the form. The operator sees the rejection at the point of scanning and can decide what to do about it.

Grace period (days) sets how long after its expiry date a document is still accepted. It is 30 days by default, which covers the usual window for renewing an identity card. Within the grace period the scan is accepted and the operator is warned how many days ago the document expired, so they can ask the visitor to renew it. Set it to 0 to refuse any expired document.

Turn it off only if your site knowingly admits people on expired documents; the consequence is that expired document details are captured silently and your records will contain them.

The Reject expired scanned documents option

The Grace period (days) field

Duplicate Visitor Detection

The second panel holds the duplicate rules for visitors.

These rules decide when a visitor is treated as somebody who is already in the system. They apply wherever a visitor is registered or added: public registration links (including group registration), the operator Add Visitor and Edit screens, kiosk check-in, group member add, edit and import, the visitor API and the dashboard quick check-in.

Before anything is compared, values are tidied up the same way on every path:

Names are compared ignoring case and surrounding spaces. There is no phonetic (“sounds like”) matching, so “Smith” and “Smyth” are different names.
Email addresses are compared ignoring case.
Mobile numbers are compared in full international form, so 082 555 0142 and +27 82 555 0142 are the same number. A number typed without a country code is read using the Default Telephone Country Code under Region, or South Africa when that is not set.
ID numbers are compared ignoring spaces, dashes and case.
An ID number shorter than 5 characters, a mobile number with fewer than 8 digits, or a value made of one repeated character (such as 0000000000) is treated as blank and never matches.

Where the duplicate rules apply

Match strategy chooses which field set is compared first, with the other used automatically as a fallback when the first is blank on either side:

ID number primary, Name + DOB fallback (the default) compares the identity number first. Best where an identity document is always captured.
Name + DOB primary, ID number fallback compares first name, last name and date of birth first. Best where identity numbers are optional or often left blank.

Email and mobile are checked alongside whichever strategy you pick; they are not part of the fallback chain.

The Match strategy selector

Email match treats a matching email address, on its own, as a duplicate. It is on by default. Turn it off where families, contractor crews or school groups legitimately share one address - otherwise the second person to register is blocked by the first.

The Email match option

Mobile match does the same for the mobile number, and is also on by default. Turn it off where a company switchboard or a single site number is entered for everyone.

The Mobile match option

Merge into an existing profile without review when decides something different. The switches above decide what an operator sees flagged as a duplicate. These boxes decide when a visitor is joined to an existing profile with nobody checking: kiosk and guard app walk-ins, approvals and invites from integrations. A merge happens only when one of the ticked boxes matches:

ID number + mobile or email
Name + surname + date of birth + mobile or email
Name + surname + date of birth (the kiosk does not capture a date of birth, so the date-of-birth boxes apply to the guard app and approvals)
Name + surname + mobile or email (a returning invitee from an integration usually gives only a name and an email)
ID number + name + surname
Mobile + email (no ID number)
ID number only, Mobile only and Email only

A visitor who matches something but none of the ticked boxes gets a new profile of their own, and the existing profile is never changed. When Invite Reuse Check is on and that existing person already has a visit in progress, a kiosk or guard app walk-in is asked to see reception instead of being given a pass. A shared mobile or email only counts here when its “Treat a matching mobile/email as a duplicate” switch is on, so colleagues who share a switchboard number are not sent to reception when that switch is off.

Each time a walk-in is sent to reception, a System Error entry in the event log records which device and which visitor profiles were involved. A kiosk or guard device that sends 10 walk-ins to reception within an hour sends every walk-in to reception until the hour is up, so typing other people’s details at a kiosk cannot be used to find out who is on site.

The first six boxes are ticked by default. The single-identifier boxes are not, and each carries a “Not recommended” warning: with them ticked, someone who types another visitor’s email or mobile at a kiosk can be joined to that visitor’s profile.

The Merge without review options

What happens when a duplicate is detected depends on where it was entered:

On the operator Add and Edit screens, a Possible duplicate found panel opens above the form, listing each matching record with the field that matched and an Open link. Open the existing record, or click Cancel. There is no option to save a second copy. See Add Visitor.
On a public registration link, the registration is stopped. A match on email, mobile or ID number is shown on that field. A match on name and date of birth shows only “We could not complete this registration. Please contact reception for help.”, so the form never reveals whether a named person is on record.
Imports and the visitor API reject the row or request, as before.

Making these rules too broad turns into visitors who cannot register at all; making them too narrow fills the system with near-identical records.

Duplicate Staff and Personnel Detection

The third panel holds the duplicate rules for staff: user accounts, personnel records and staff self-registrations. It covers the operator Add and Edit screens for users and personnel, user and personnel import, the user and personnel API, and staff self-registration. Values are tidied up exactly as for visitors (see above).

The login email and username of a user account are always unique, whatever this panel says. A clash on either is shown on the field when you save, and automatic account creation (SSO login and approving a staff self-registration) only ever checks these two, so these rules can never stop someone from logging in.

The Duplicate Staff and Personnel Detection panel

Match strategy is shared by every kind of staff record and works as it does for visitors: the ID number or the name and date of birth is compared first, with the other as the fallback.

The staff Match strategy selector

Below it, a grid sets the rules for each kind of staff record separately. Each column is one kind: User accounts, Personnel and Staff self-registrations. Tick a box to treat a match on that detail as a duplicate for that kind. Changing one column never changes the others. The defaults keep the checks each kind had before the grid existed.

The Check for duplicates row chooses which kinds are checked at all:

User accounts is off. Users are then checked only on their login email and username. Turn it on to also check users on ID number, mobile number, staff ID and, with the Name + DOB strategy, name and date of birth. A user’s date of birth is an optional field on the user form.
Personnel is on.
Staff self-registrations is on.

The Check for duplicates row of the staff grid

The Email address, Mobile number and Staff ID or employee number rows make a matching value count as a duplicate on its own:

User accounts check the mobile number and staff ID by default. The email cell shows a dash: a user’s email is their login email and is always unique, so it is never used here.
Personnel checks all three by default.
Staff self-registrations check the email address and mobile number by default, but not the employee number. Untick the email box if several applicants share one address.

The Email address row of the staff grid

The Name fallback row decides, for each kind, when a staff record may be matched on names:

When all identifiers are blank uses names only when the ID number, mobile number, email address and staff ID are all empty, so only for a record that has nothing else to compare. This is the safest choice and the default for user accounts and personnel.
Never use names ignores names entirely; only the identifiers can match. This is the default for staff self-registrations.

The Name fallback row of the staff grid

When a staff duplicate is detected on the Add or Edit screen for a user or a person, the same Possible duplicate found panel opens as for visitors (see Add Personnel). An operator who may not open the matching record sees only the field that matched and “The matching record is not available to you.”, never the person’s name. A matching visitor the operator may not open is left out of the visitor panel. On the staff self-registration form, a match on name or staff number shows only “We could not complete this registration. Please contact reception for help.”

Which fields must be captured at all, per channel, is set under Configuration > Visitor Settings > Required Fields and the equivalent kiosk, guard and web service pages.
Retention of the personal data these rules govern is set under Privacy.
Regional defaults such as the telephone country code are set under Region.