Skip to main content
An Access Policy is the ruleset a Sign-In Context consults every time a guest arrives at the Captive Portal (or signs into the Self-Service Portal). A policy answers three questions:
  1. Who does this policy apply to? — matched by email pattern or email domain.
  2. Which Sign-In modules is this guest allowed to use? — Meeting Host, Email Self-Provisioning, SAML.
  3. Which Self-Service actions can this guest perform? — Manage Conferences, Manage Whitelistings.
Every Context has a default policy that catches anyone no other policy matches. You can add additional policies and give each a list of email patterns to define its audience.

​
Where policies live

In the Sign-In Context admin, open the Captive Portal → Access Policies section in the left navigation. The list view shows, for each policy:
  • Name
  • Who (Applies To) — the email patterns
  • Sign In Permissions — teal pills per enabled Sign-In module
  • Self-Service Permissions — green pills per enabled Self-Service action, or a red Self Service Not Enabled pill when the Self- Service Portal is off for the policy
Click a row to open the policy editor.

​
The editor — three tabs

Each policy editor has a shared header with three cards — Policy Name, Self-Service Portal (the master-switch for this policy’s Self-Service actions), and Site Based Redirect (when on, defer this policy’s redirect to the per-Site URL in Sites Configuration). Below the header, the editor has three tabs:

​
1. Applies To

The single set of email patterns that decide who this policy matches. One pattern per line. Leave empty on the default policy — it’s the catch-all.

​
2. Sign-In Permissions

Three sub-tabs, one per policy-gated Sign-In module:
  • Meeting Host — enable the Meeting Host flow for matched guests; configure the redirect URL, the default visit duration, and the maximum number of days a host can schedule a meeting in advance.
  • Email Self-Provisioning — enable self-provisioning via email; configure device quotas, redirects for new / returning / verified guests, verification-mail behaviour, device-limit policy (allow, notify, or require approval), and session length (fixed timeout or a concrete end date).
  • SAML Login — enable BYOD sign-in with SAML; configure the redirect, device quota, and session length (timeout or end date).
The remaining Sign-In modules (Quick Access, SMS, Radius, Password, Username & Password, Event Access, Blacklistings) aren’t gated by Access Policy — if the module is active at Context level, it is available to anyone who reaches the Captive Portal.

​
3. Self-Service Permissions

Two sub-tabs:
  • Manage Conferences — allow matched Self-Service users to create and manage Conference-code sign-ins; configure the default conference URL, default and maximum conference length, and visitor limits.
  • Manage Whitelistings — allow matched Self-Service users to whitelist devices by MAC address; configure the length policy (forever, a fixed number of days, or a calendar end date), maximum active entries, and calendar defaults.
The Self-Service Permissions tab is disabled when the policy’s master Self-Service Portal toggle is off.

​
Other permission pills

The policy list shows two additional Self-Service pills — Manage Guests and View My Devices — that don’t have their own toggle. They follow the master Self-Service Portal toggle: when it’s on, any guest who authenticates to the Self-Service Portal can view their own devices, and guests with the Meeting Host permission can manage invited guests.

​
A worked example

Suppose an Organization runs two audiences on one Sign-In Context:
  • General guests — short visits, self-provision by email.
  • Contractors — week-long engagements from a specific vendor domain, with SAML preferred.
Two policies cover this:
  • default — no email pattern; Sign-In Permissions has Email Self-Provisioning on with a 4-hour session and a one-device quota.
  • contractors — one email pattern matching the vendor domain; Sign-In Permissions has SAML Login on with a 5-day session and a two-device quota, plus Email Self-Provisioning as a fallback.
Both policies live in the same Context. The most-specific match wins; everyone else hits default.

​
Relationship to the rest of Sign In

  • Policies are per-Context. Each Sign-In Context has its own set.
  • A policy decides who can use which policy-gated module, and on what terms. Whether the module is active at all is decided at Context level on the module’s own page.
  • Login events (signin.session.*) carry the policy that was evaluated — useful for auditing which policy granted access.

​
Next

Sign In Modules

The authentication methods policies can enable.

Sign-In Context

How Contexts and policies fit into the Organization.