Access Invites

Part of the IP4CMS portal. ← All module guides

What it's for Access Invites lets your organisation issue time-limited gate access to visitors and contractors. You create an invite for a person, the system generates a secure credential (a PIN, OTP, QR code or biometric), and that credential is pushed to the access-control hardware guarding your sites. Each invite has a reference, status, validity window and a record of the credential issued. It is the operator-facing front of the wider Access Management system: members can also raise their own invites from the member portal, and those land in the same list you manage here.

Where to find it In the portal side menu under Access Invites (/app/access-invites); click a row to open its detail page. Supporting configuration (entry types, points of entry, channels) lives under Settings → Access at /app/settings/access.

Before you start

• Licence / module: The access_management module must be enabled for your tenant. Every screen here is gated behind it, so if the module is off the menu item and pages won't appear.
• Permissions: Controlled by the access_management:* family (full breakdown below). admin:full:access grants everything; otherwise you need the specific permission per task—access_management:invites:create to create, access_management:invites:read to view.
• Configuration first: Before sending a usable invite you normally need at least one access-management channel (the bridge to your gate hardware), one entry type, and—depending on the channel—points of entry, all set up once under Settings → Access.

Key tasks

Task: Create a visitor invite

1. Open Access Invites from the side menu.
2. Click New access invite. A dialog opens.
3. Fill in the fields (see below), then click to save. If Issue credential is ticked the system immediately generates the credential after saving and, if Send notification is ticked, notifies the visitor.
4. On success you get a confirmation with the new reference number. If a visitor link was generated, the message reminds you to copy or send it using Issue / Resend on the detail page.

Fields in the New access invite dialog:

• Location — the site this invite is for (from your Locations list).
• Channel — which gate-control integration handles it. Optional; if blank the system falls back to the entry type default, the location link, then the tenant default. Only active channels listed.
• Entry type — the category of visit (e.g. "Contractor", "Guest"), driving credential methods, onboarding requirements and allowed points of entry. Only active entry types listed.
• Visitor name (max 200), Visitor phone (max 50), Visitor email (valid email if supplied).
• Valid until — expiry date/time. Defaults to seven days from now.
• Require visitor selfie — when on, the visitor must supply a selfie (for face-verification flows).
• Issue credential — on by default; generates the credential as part of creation.
• Send notification — off by default; when on the visitor is messaged with their invite/credential.

New invites start in draft, then move through pending, accepted, cancelled or expired as they are sent, used, withdrawn, or run past their validity window.

Task: Manage an invite (issue credential, run actions)

1. From the list, click an invite row to open its detail page, showing the reference, status, any channel output and the credential record.
2. Issue credential — (re)generates and pushes the credential. Use it to issue a credential you skipped at creation, or to resend.
3. Actions — context-sensitive buttons returned by the system for the invite's current state (e.g. accept, cancel, resync, revoke). The list depends on status and the channel's capabilities. Click one to run it; the result is shown and the page refreshes.

The list page also lets you search (reference, visitor name, visitor email or location), filter by status (draft / pending / accepted / cancelled / expired) and sort.

Task: Set up entry types

Entry types are templates that decide what a visit requires. Configure them under Settings → Access → Entry types.

1. Click Add entry type.
2. Complete the form and save.

Key fields:

• Code — short machine code, lowercase letters/numbers/underscores, unique per tenant.
• Name and Description.
• Active and Sort order.
• Onboarding type + Require onboarding before accept — link the visit to an onboarding flow and force it to complete before the invite can be accepted.
• Require visitor selfie (default) and Require liveness check (default) — pre-tick these requirements on new invites of this type.
• Credential methods — which gate proofs apply: PIN, OTP, QR, Fingerprint, Facial, Liveness, Driver licence. Defaults to PIN.
• Credential combination mode — Any (the first successful proof opens the gate) or All (every selected proof is required).
• Who can send (invite sender member types) — restricts which member types may raise this entry type from the member portal. Blank/null means any member with invite permission; empty means none.
• Invite notify template — the message template used when notifying visitors. Falls back to the access settings default if blank.
• Allowed points of entry — when set, invites of this type may only target these points of entry; blank means any.
• Default channel — the preferred access-management channel for this entry type; overrides the location link and tenant default.

Task: Set up points of entry

Points of entry (PoEs) are the physical gates/turnstiles at a location. Configure them under Settings → Access → Points of entry.

1. Click Add Point of Entry.
2. Choose the Location (required, fixed after creation), give it a Name (required), an optional Description, and set Active.
3. Save. Edit or deactivate existing PoEs from the same list.

PoEs are used by entry types' "Allowed points of entry" allowlist and by gate validation.

Task: Set up access-management channels and handlers

A channel is the connection between IP4CMS and a physical access-control system. Configure them under Settings → Access → Channels.

1. Click Add access channel.
2. Pick a Handler. Built-in handlers include OpenItem and Fortress; the picker is populated live from the server, so it reflects what is installed for your tenant.
3. The form then shows the configuration fields that handler needs (e.g. API URLs, keys, device identifiers). Required fields are validated, and some appear only when a related field has a particular value.
4. Fill in Code (letters/numbers/underscores, unique), Name, Display order and Active, then save.

Choosing a handler also shows capability chips for what the integration can do: Customers, Contacts, Customer↔contact link, Issues PIN, Syncs PIN, Inbound validation, Face verification, Remote revoke and Pulse gate. After saving, if the handler supports inbound validation an inbound webhook block is shown for wiring the gate device back to IP4CMS.

Channels can be linked to locations and one can be set as the tenant default under Settings → Access → Settings.

Task: Understand credentials

Credentials are created for you—you don't hand-enter them. When an invite's credential is issued, the system creates one access credential record per applicable method (PIN, OTP, QR, fingerprint, facial, liveness). PINs are stored hashed; QR credentials carry a signed payload. Each credential tracks use count versus max uses, its expiry, and whether it has been revealed or revoked. Revoking is done via the actions on the invite detail page (where the channel supports remote revoke); you see a credential's effect in the invite's channel output panel.

How the data connects

• A Location has one or more Points of entry (physical gates) and can be linked to one or more Access-management channels.
• An Access-management channel runs a handler that talks to the real gate hardware and declares its capabilities.
• An Access entry type is a reusable template setting credential methods, onboarding rules, an allowed-PoE list, a default channel, and which member types may use it.
• An Access invite is created for a visitor at a location. It snapshots the entry type's requirements, resolves a channel, and—once issued—produces one or more access credentials. The invite carries the reference, status, validity window, visitor details, channel output and sync state.
• Channel/entry-type/tenant settings decide which channel and message template apply when an invite doesn't specify its own.

In short: channel + entry type + point of entry are the configuration; invite → credential is the live record produced per visitor.

Permissions & access

All permissions are in the access_management:* family. admin:full:access is a super-grant covering all of them. The specific ones:

Every route also requires the access_management module to be enabled.

Tips & gotchas

• Configure before you invite. Without an active channel, an entry type and (often) points of entry, an issued credential has nowhere to go.
• The visitor link is delivered via Issue / Resend. When creation returns a public token, get it again from that button on the detail page rather than expecting it in the list.
• "Issue credential" defaults on, "Send notification" defaults off. Tick Send notification if you want the visitor messaged automatically at creation.
• Channel left blank is fine. The system resolves it from the entry type default, then the location link, then the tenant default.
• Credential combination mode matters. "All" requires every selected method to succeed at the gate; "Any" opens on the first success.
• Allowed points of entry is a hard allowlist. If an entry type lists specific PoEs, its invites cannot use any other gate.
• Capability chips are your truth source. Before relying on PIN sync, face verification or remote revoke, check the chips on the chosen handler.
• List filtering is client-side, running over the already-loaded invites.
• Partial success on create. If the invite saves but credential issue fails, you get a warning, not an error—the invite exists; reissue from the detail page.