Skip to main content

Creating a Policy: Fields, Conditions, and Approval steps

Learn the basics of creating an Advanced Approvals Policy to ensure the security of your workplace.

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 (both Host and Admin), 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 when creating an invite. Used to route the workflow through conditions.

  • 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:

  1. Create a draft policy using the provided policy builder tools

  2. Publish the policy to make it available for association

  3. Associate the policy with sign-in flows – once associated, the policy becomes enforced for all invites that go through those sign-in flows

Policies are enforced at the start of a visit, either when a host creates an invite or, when walk-ups are enabled, when an unexpected visitor starts a sign-in flow on the iPad. In either case, 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, 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 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:

  1. Navigate to Global overview > Visitors > Policies. Click Create policy.

  2. 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.

  3. 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.

Two types of policy fields are available:

  • Host (Inviter) 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.

Host (Inviter) Fields

  1. Under Policy Fields, click + Add field.

    1. If you don't see this option, you might need to click the caret to open the dropdown.

  2. This process is similar to creating a sign-in field in a sign-in flow. Add your field name.

    1. Designate who is responsible for filling in the field. By default, the Host (Inviter) is selected.

    2. Set the Answer type. For Host (Inviter) fields, only Multiple choice is available.

    3. Create the options. You cannot have fewer than 2.

      1. To add more options, click + Add option.

      2. To reorder options, click and drag the toggle.

      3. To delete an option, click the trashcan.

  3. Click Create to complete.

  4. 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

  1. Under Policy Fields, click + Add field.

  2. Add your field name.

  3. Select Admins for the To be filled by setting.

  4. Set the Answer type. For Admin fields, these can be multiple-choice or freeform text.

  5. For multiple choice, add the options accordingly.

  6. Click Create.

Adding the Data collection step

After creating your Admin field, you'll need to add a Data Collection step.

  1. Add a Data Collection step at the point where you want the field filled in.

  2. Give the step a name. This shows on the approval workflow, so it's good to make it concise.

  3. Assign the collector(s), typically the team responsible for that approval step.

  4. Select the field(s) to collect at this step. The policy fields labeled will appear in the drop-down.

  5. (Optional) Set a location override, allowing different admins to collect data according to their location.

  6. When adding your Data Collection step to your policy, connect the step to the relevant Approval step.

    1. You can place it before the decision (collect first, then approve) or after (approve first, then collect).

    2. 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.

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.

  1. Within the Policy builder, click Condition to add a new step to the workflow builder.

  2. Click on the new condition to select. The condition details will open in the right-hand side panel.

  3. 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.

    1. The IF condition requires an IS or IS NOT correlation to an option.

    2. The ELSE condition captures the other answers to the policy field.

  4. 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.

  1. Within the Policy builder, click Approval to add a new step to the workflow builder.

  2. Click on the new approval to select. The approval details will open in the right-hand side panel.

  3. Begin by giving your approval step a descriptive name, such as 'Security Review' or 'Executive Approval.' This label will show in the workflow builder.

  4. Define who will be responsible for approving this visit. Currently, this is limited to Global and Location admins.

    1. 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.

    2. SCIM groups: If you use SCIM to manage your directory, you can create groups within your IDP to use as potential approvers.

  5. Once approvers are added, the step will be saved automatically and will be ready for use within the workflow.

Related Articles
About Advanced Visitor Approvals
Enable walk-up visitors for Advanced Approvals
Complex Policy steps: Concurrent approvals, Location overrides, and Risk intel
Building, Publishing, and Using Your Policy for Advanced Approvals
Approving visits, Data Collection, and Invitation Experience for Advanced Approvals
Did this answer your question?