Overview
A Policy is a configurable container that houses the conditional rules and approval logic for visitor requests; think of it as the "brain" of your approval workflow. It defines who needs to approve what, under which circumstances, and in what order.
This article walks through creating a new policy and configuring its core building blocks: policy fields (Host, Admin, and Visitor), the Workflow trigger, Condition steps, and Approval steps. By the end, you'll have everything you need to build a straightforward linear approval workflow.
For more advanced step types, such as Concurrent approvals, Location Overrides, and Risk Intel, see Complex policy steps.
Building your Policy
Policy basics
A policy can include any combination of these building blocks:
Policy fields: Information collected from the host, visitor, or admin during the invitation and/or entry process.
Approval step: Assigns a specific person or group to review and approve or deny the invite.
Conditions: Branches the workflow based on visit data.
Concurrent step: Sends the invite to multiple approvers simultaneously.
Data Collection step: Prompts a designated person to fill in specific fields before the workflow continues.
Risk Intel step: Adds screeners like Visit Frequency to the workflow.
Policies support versioning, so you can maintain different published versions and roll back when needed. Publishing creates a new version. Sign-in flows associated with a previous version continue to use that version until you bump them to the new one.
See Building your policy for how to move a sign-in flow to the new version.
How Policies work
Policies work alongside your existing sign-in flows through a simple three-step process:
Create a draft policy using the provided policy builder tools
Publish the policy to make it available for association
Associate the policy with sign-in flows – once associated, the policy becomes enforced for all invites that go through those sign-in flows
When the approval process actually occurs depends on how your information is collected.
For invite approvals, the process begins when a host creates an invite.
If walk-ups are enabled, an unexpected visitor starts a sign-in flow on the iPad, kicking off the approval chain.
If you require pre-registration, the approval process can start after all visitor-provided information has been provided.
In all cases, the visit runs through the policy workflow. Once all required approvals are obtained, the invite email is sent (if selected during invite creation) or, for walk-ups and pre-registration, the visitor is cleared to sign in.
If any approval step results in a denial, the entire visit is denied and requires a new invite or a new walk-up attempt.
Creating a Policy
Policies are comprised of three main components:
Policy fields: These are pieces of information about a visit used to determine the appropriate actions for the visit. They can be collected from Hosts during invitation creation, visitors during pre-registration, or admins during a data collection step.
Approval steps: These are the steps where someone approves or denies an invitation. Individuals and SCIM groups can be responsible for approval. You can set location overrides so each location has a different admin responsible for completion.
Conditions: Steps that create intelligent routing based on visitor responses.
To begin creating your new policy:
Navigate to Global overview > Visitors > Policies. Click Create policy.
Give your policy a Name and Description. Since these policies are global, it's a good idea to keep names concise and descriptions straightforward. Click Create.
After creation, you should be taken into your new policy to start building.
✨Tip: You can change the name and description of your policy after creation by clicking into the title text box. ✨
Policy Fields
Policy fields are the information that must be provided during the approval process. Host-provided fields are automatically inserted into the invite form.
as seen on an invite using the associated visitor sign-in flow
Admin-provided policy fields are used during data collection steps.
as seen on an invite using an admin approver field
Based on the dropdown selections made, you can create routing branches that connect to different approval steps by building corresponding approval paths.
Three types of policy fields are available:
Inviter (Host) fields: Visible and editable by the host when creating an invite. Supports dropdown selections. Used to drive conditional routing in the workflow.
Approver (Admin) fields: Visible and editable only by designated approvers, hosts, and admins. Supports free-form text and multiple choice. Used to collect structured information during the approval process, such as an internal security ID or zone access confirmation.
Visitor fields: Completed by the visitor themselves during pre-registration (or at the iPad on arrival). Use these when the information must come from the visitor.
In addition to any Inviter, Approver, or Visitor fields, you can add Conditional fields to collect extra information if necessary.
Inviter (host) Fields
Under Policy Fields, click + Add field.
If you don't see this option, you might need to click the caret to open the dropdown.
This process is similar to creating a sign-in field in a sign-in flow. Add your field name.
Designate who is responsible for filling in the field. By default, the Host (Inviter) is selected.
Set the Answer type.
Create the options. You cannot have fewer than 2.
To add more options, click + Add option.
To reorder options, click and drag the
toggle.To delete an option, click the
trashcan. To add a conditional field, click the
chart icon.
Click Create to complete.
Now that you have a policy field, you can use it within the policy builder to define conditions.
Approver (Admin) fields
Admin fields collect structured information from specific reviewers (often the approver) during the approval workflow, separate from what the host fills in. This is useful when an approver needs to document a decision, such as recording a program number, confirming zone access, or logging a security ID. These fields are not visible to the visitor and are saved to the invite record once completed.
Creating the admin field
Under Policy Fields, click + Add field.
Add your field name.
Select Admins for the To be filled by setting.
Set the Answer type. For Admin fields, these can be multiple-choice or freeform text.
For multiple choice, add the options accordingly.
Click Create.
Adding the Data collection step
After creating your Admin field, you'll need to add a Data Collection step.
Add a Data Collection step at the point where you want the field filled in.
Give the step a name. This shows on the approval workflow, so it's good to make it concise.
Assign the collector(s), typically the team responsible for that approval step.
Select the field(s) to collect at this step. The policy fields labeled
will appear in the drop-down.
(Optional) Set a location override, allowing different admins to collect data according to their location.
When adding your Data Collection step to your policy, connect the step to the relevant Approval step.
You can place it before the decision (collect first, then approve) or after (approve first, then collect).
For our example, we would place the Escort Assignment step after the assignment approval, since we would not assign an Escort until after the invite is approved.
Visitor fields and pre-registration
When you set a field's To be filled by option to include the visitor, the visitor is responsible for providing (or confirming) that information.
There are two visitor-facing options:
Inviter + Visitor: The host must enter an initial answer on the invite form. The visitor can see that answer and update it during pre-registration or at the iPad.
Visitor only: Only the visitor provides the answer, during pre-registration or at the iPad.
Once any policy field allows visitor input, we highly recommend including a pre-registration node in your workflow.
If a condition is created based on a visitor-input policy field, pre-registration is required and can't be switched off by a location admin. It's the only way to collect a visitor-only field before arrival.
The pre-registration form locks once submitted.
After a visitor submits their pre-registration, they can't change their answers through the pre-registration link. The submission is timestamped for your audit trail. If something needs to change after submission, an admin can update the field on the invite record. This is reflected in the History log.
Conditional fields
Conditional fields are policy fields that are collected only if a prior policy field answer requires it. These fields are hidden unless "activated" by the answer to a previous question/field.
Before creating a conditional field, you'll need to have a policy field to connect it to.
To create a conditional field:
Click on + Add field.
Give your field a Name (question), and assign it to the Inviter, Admins, Visitors, or Inviters and Visitors.
Tip: Match the assignee to the parent question. A conditional field always inherits its parent question's assignee, so any different selection here will be overridden.
Select an answer type: Multiple choice or Freeform text.
If multiple choice, fill out each answer option.
Toggle Make this a conditional field to On.
Now, create the condition that displays the additional field.
The logic is straightforward: if X is Y, Z appears.
Click Create to finish making your conditional policy field.
Your target policy field will update to indicate that a conditional field is attached.
Once your conditional field is created and attached to a target field, you'll be able to work it into your policy.
Workflow trigger
Every policy begins with a Workflow trigger node. By default, a policy’s Workflow trigger does not allow Walk-ups or unexpected visitors.
As a result, sign-in flows linked to that policy are hidden on the iPad for Walkup visitors to select. Any invited and approved visitors can still sign in on the iPad
To allow walk-up visitors, enable walk-ups on the workflow trigger.
Conditions
Conditions are steps that determine the flow of a visit through the workflow.
Within the Policy builder, click Condition to add a new step to the workflow builder.
Click on the new condition to select. The condition details will open in the right-hand side panel.
Here, you can define the outcomes of an invite based on your policy fields. Each outcome will create a new node, on which actions can be built.
The IF condition requires an IS or IS NOT correlation to an option.
The ELSE condition captures the other answers to the policy field.
Each node can now be used to create a new branch. You can click and drag the node to create branches in your workflow.
Approval step
Approval steps allow designated admins to approve or deny visits.
Within the Policy builder, click Approval to add a new step to the workflow builder.
Click on the new approval to select. The approval details will open in the right-hand side panel.
Begin by giving your approval step a descriptive name, such as 'Security Review' or 'Executive Approval.' This label will show in the workflow builder.
Define who will be responsible for approving this visit. Currently, this is limited to Global and Location admins.
Multiple approvers listed: You can select multiple approvers. When any one of them approves, the visit advances to the next step in the workflow. This option does not require each admin listed to approve.
SCIM groups: If you use SCIM to manage your directory, you can create groups within your IDP to use as potential approvers.
Once approvers are added, the step will be saved automatically and will be ready for use within the workflow.