Overview
Approval workflows let you build conditional approval workflows using Policies, a configurable container that defines who approves what, under which circumstances, and in what order.
Visual Compliance, OCR EASE, and MK Denial are restricted party screening solutions that check whether a visitor's information appears on any restricted-party lists you've selected. Identity Screening (by Checkr Trust) screens your visitors against selected criminal database(s).
You can add these screeners as a step in your Policy to strengthen and streamline your approval process. The outcome of that step (whether the visitor matches a restricted party) can branch the flow and route the visit to a specific approver, such as your trade compliance or security team, before clearing the visitor. This keeps all approvals routing to the correct team(s), ensuring your invites are appropriately approved.
PREREQUISTES
You'll need to connect your Envoy account to a screener before you can add it to a policy. You will need to install screeners at every location where you want to use a policy. If the screener is not installed, the step will be skipped. If you have flows already paired to a policy, you'll receive an error for any location missing a screener.
See our configuration guides:
Building a Policy with Screeners
Step 1: Create or open your policy
Navigate to Global overview > Visitors > Policies and Create a policy or open a draft of an existing policy.
If you're creating your policy, give the policy a concise Name and Description, then click Create. You'll be taken into the policy builder, which opens with a Workflow trigger node.
Learn more about building a policy.
Step 2: Add the Screener step
Each screener has a slightly different configuration process.
MK Denial
In the policy builder, click the individual screener you want to add.
Your new step will appear in the canvas. Click on the step to open its settings.
Give your step a name. By default, it'll be titled Risk Tool.
Mk Denial has the ability to screen Visitor name, Company, and Address. Visitor name is required, and you can select any additional field you want to screen.
For Company, you can select a policy field, or Create a company field to add one.
For Address, select the granularity: City, State, Country or Full address.
OCR Global Ease
In the policy builder, click the individual screener you want to add.
Your new step will appear in the canvas. Click on the step to open its settings.
Give your new step a name. By default, it'll be titled Risk Tool.
Select the Address field granularity.
City, State, Country
Full address
The system will automatically add any fields not included in your sign-in flow. You can change the field label that visitors see by entering a new one, or leave the box blank to use the default.
Identity Screening
In the policy builder, click the individual screener you want to add.
Your new step will appear in the canvas. Click on the step to open its settings.
Give your new step a name. By default, it'll be titled Risk Tool.
Select a policy field to be used for Date of birth. If you do not already have one in your policy, you can add one now.
Visual Compliance
In the policy builder, click the individual screener you want to add.
Your new step will appear in the canvas. Click on the step to open its settings.
Give your new step a name. By default, it'll be titled Risk Tool.
Visual Compliance can screen Visitor name, Company, and Address. Visitor name is required, and you can select any additional field you want to screen.
For Company, you can select a policy field, or Create a company field to add one.
For Address, select the granularity: City, State, Country or Full address.
Step 3: Connect your Screener step to your policy workflow
Decide where you want your screener step to run in relation to the rest of the policy. You have the option to screen all visitors by including the screener step at the beginning of the policy, or only screen visitors who meet certain conditions
Connect the step so it runs at the point where you want screening to happen.
The step will produce an outcome (Not flagged/flagged) that you can branch on in the next step.
Step 4: Assign an approver to the Flagged branch
Here, you can assign a specific person or group to approve/deny the screener match. The screener step does not include an approval process; it only runs the screening.
Click the Require approval step in the sidebar to add an approval step to the canvas.
Click on the new step to show details. Give the step a name. This label shows in the workflow builder.
Set a Default Approver.
(Optional) Set a Location Override, allowing you to define different approvers depending on the location of the visit. Learn more about location overrides.
Step 5: Complete the Flagged path by adding it to your Policy
Click on the Flagged node on your screener step.
Connect this path to your recently added approval step.
Connect the node on your approval step to the rest of your workflow.
Once your step is connected, you can continue to build/modify the remainder of your policy. See main article: Building, Publishing, and Using Your Policy for Approval workflows.
Approving/Denying a Screener match
When an entry or invite is flagged in your corresponding screener, Approval workflows replace the traditional screening workflow.
Match details can be viewed in the Advanced Approval Process workflow window by clicking the 
chart button.
You can also open match details by clicking on either Approve or Deny.
You can add an optional reason when completing an approval or denial.
The History log will update to note the flag, as well as the approval/denial. This update is saved automatically and cannot be edited.
Screeners in a traditional sign-in flow vs. Screeners in a Policy
It's worth understanding what changes when you move screening inside a policy, instead of using a standard sign-in flow:
Routing is explicit. Instead of only notifying a list of alert recipients, a match sends the visit to a named approval step with defined approvers.
Decisions are sequenced. The visit can't proceed past the approval step until the assigned approver acts, so screening becomes a gate rather than a parallel notification.
The audit trail is richer. Approver comments and any Data Collection fields are saved to the invite record and reflected in the History log.
Screening can run at pre-registration. When you require pre-registration, visitors provide their information before the approval process starts, so the screener step can check against complete visitor data and route matches to an approver ahead of arrival, rather than catching them at the kiosk. Depending on the policy, screening and approval can wait for pre-registration to finish or run at the same time. Learn more about Pre-registration for Approval workflows.
The workflow is flexible. Because screening is just one step in the builder, you can place it wherever it fits, combine it with conditions and other steps, and add as many branches as you need. Screen only certain visitor paths, chain screeners with additional approvals or Data Collection, and rearrange steps at any time.