Overview

When presenting Best Practices to you, our customers, we offer them as Recommendations, not Rules. A recommendation works best, in the provided context, 99.99% of the time. But there are always edge cases along with different use cases that change the context. And workflows, due to their flexibility of use, can be utilized in countless use cases. With this article we’ll focus on some common use cases.

Decisioning Workflow Goals

• Surface to reviewers key information from the inquiry and workflow verifications in the form of tags
• Action off the tags to move the inquiry, even via a case, towards a post-inquiry status

You can capture a variety of information in the form of tags:

• Device or IP signal tagging
• Tagging specific inquiry fields like age
• Tagging verification check failures— where the customer did not require the verification check but wanted failures to be manually reviewed

You’ll need to determine what information you want to capture as a tag either for the reviewer, to help with automation, or for improving search.

Custom tags

Tags are custom objects that can been named whatever you what, so we recommend selecting very descriptive tag names. Also, you should only create new tags as you need them to avoid keeping track of tags for every unnecessary variable. You can manage tag in the Tag Manager.

• Verifications: Since verifications have two outcomes (passed, failed, not-applicable) you can create tags for each state of a verification, but we recommend creating just the failed versions. So you might have “GovID-Failed” and optionally “GovID-Passed” and maybe even “GovID-NA”.
• Inquiry Signals: We recommend that for Inquiry Signals to just copy the name of the signal with the relevant level like “Behavior Risk High”.
• Reports: Many reports are structured on getting a “hit” if information is found. That’s why for many reports you can just tag with something like “Business Verification Hit”.

Post Inquiry-Phase

The primary utility of an inquiry is to inform a decision, allowing you to move forward on a business action with that entity. And the best representation of that choice is the inquiry moving to either the “Approved” or “Declined” status. You can set up webhooks to listen for when those events happen and then your systems can move forward with the related business action or not.

• To that goal, workflows should end in an “Approved” or “Declined” status
• If using a Case for manual review, make sure the Case Resolution updates the Inquiry status
  • You will in most situations set up a “Wait for case resolved” step at the end of your workflow and once the case is resolved the workflow with update the Inquiry status accordingly
  • You can set up webhooks to also listen for case status updates, not just updates from inquiries.

Guidelines

1. Structuring your workflow
2. Always decision the inquiry
3. Case Considerations
4. Lists
5. Ordering of workflows
6. Reports Erros

Structuring your workflow

1. At the top: Apply tags based on the inquiry
2. In the middle: Non-Inquiry steps like reports, graph queries, etc
3. At the bottom: Decision the inquiry (approve, decline, or Mark for Review)

At the top: Applying Tags

Parallel Paths

When applying tags, we recommend to handle their logic via parallel paths, with each path getting a separate conditional branch. We create a parallel step here for two reasons:

• Each of the conditionals can run independently from each other, so processing them “in parallel” will be speedier
• It helps with visualization of the workflow since the parallel doesn’t take up too much vertical space

You’ll want to use the Tag Object step, which you can read up on here.

If the inquiry already meets the criteria for an auto-decline, you can do it here and save yourself the cost of running any reports.

In the middle of the workflow is where you want to:

• Run reports
• Query Graph
• Run verifications outside of the inquiry
• Tag all the results

This is a similar loop to the ‘top’ part of the workflow, focused now on adding additional data and then tagging based on the results.

Report and Tagging

Below are two examples of reports being run and then conditionally tagging based on the results. In the first example with the Business Registration report, the conditional paths tag on a “Match” and on “No Match”. In the 2nd example with TIN Database, it only tags on Failed and Unavailable while Passed is not. This reflects a prioritization of problems being flagged and tagged. You can adapt your tagging to reflect your priorities.

Example 1: Tagging Business Registration Verification Example 2: Tagging TIN Database Verification

At the bottom: Decision the inquiry

Now that you’ve tagged your inquiry you can start building the logic that will move it via the workflow to a terminal state. We recommend building the logic to flag the inquiries you want to mark the inquiry and/or case for review first, and having the else branch auto-approved everything else. Then after your review team has reviewed the case, the workflow can move forward with conditionally approving or declining the inquiry.

Always decision the inquiry - when inquiries fail

We recommend setting up workflows not only for when an inquiry is completed, but another just for when it fails. You can use the “On Inquiry Failed” workflow to move that inquiry to the “Declined” status.

• One triggered on inquiry.completed → move towards Approve inquiry
• One triggered on inquiry.failed → move towards Decline inquiry

Placing Case steps within the Workflow

Creating and populating a Case via a workflow requires related steps, but also some consideration of when and where to place them within the Workflow sequence. This can be chunked in to three key phases: Case Creation, Case Population, Case Status Update.

Case Creation

The placement of the Create Case step should be very early in the workflow, certainly before you begin applying any tags. The case must first be created so you can then tag the case and attach objects to the case.

Case Population

As you move through the first two recommend workflow phases, Applying Tags and More Context and Tags, you’ll want to use the Tag Object step for tags and the Attach Object To Case step. We recommend building in these steps in small conditional chucks. In the above example from our Example KYB Solution, after the TIN Database is run, that run is attached to the case. Then the conditional will tag the case depending if it Failed or didn’t respond. This keeps all the related logic for TIN Database in one area of your workflow, and avoids your developers from losing track of related elements.

Case Status Update

Finally down in the Decisioning phase of the workflow, you can use the same logic that you would to determine if an inquiry should be Approved, Declined, or Marked for Review, but now you also update the Case Status version of Marked for Review, “Open”. In the event that your logic Approves or Declines the Inquiry, you can also do the same for your Case.

Resolving the Inquiry via the Case

As our generic workflow goal is to help resolve an Inquiry into either Approved or Declined, we want the resolution of the Case to cause the Inquiry to be resolved too. There are three ways to accomplish this with increasing automation:

• Your reviewers navs to the inquiry and manually resolve it. Very inefficient.
• Your case template includes a Case action that when triggered by the reviewer, updates the status of the Inquiry, requiring an extra click or two.
• The inquiry status is resolved by a workflow after the case status is resolved, which is fully automated.

To resolve the inquiry based on the case by workflow, you have two options to resolve the inquiry: Have the workflow that created the case resolve it or have a separate workflow that riggers off of the resolved case status update the inquiry. Below you can see an example of a workflow that waits for the Case to be resolved before conditionally resolving.

Managing Case Templates

When creating case templates for manual review, you can avoid confusion by limiting the number of types of Case Templates created, i.e

• One case template for all manual review efforts or
• Two case templates:
  • One for for Report hits (which a Compliance-focused team reviews)
  • One for everything else (verification issues, potential fraud signals)

There are a few ways to control asynchronous activity in Workflows:

1. Wait Steps (less than 30 days)
   • Wait Steps have a validation that force a default resolution time no greater than 30 days.
2. Manual Run Workflows / Scheduled Workflow step (+30 days)
   • For this reason, if you need to model a very long-lived (e.g. a 6 month redaction policy), we recommend using Manual Run Workflow / Scheduled Workflow step.

Ordering of workflows

Workflows will execute in the order they are triggered. So even if you plan or expect Workflow A to execute before Workflow B, if B triggers first it will execute first.

For example, if two workflows are separately triggered by inquiry.created and inquiry.completed respectively, then the inquiry.completed workflow should not assume the other workflows have fully executed before it began.

For another example, if you set up one workflow to trigger on inquiry.completed and another for inquiry.failed but there is a path where failed inquiries can get overturned back to completed, you can end up with both workflows running.

Expecting Prior Workflows

If your expected path includes a sequence of workflows, with later workflows relying on data generated in earlier workflows, there are two options on how to build and setup that data.

• One option is to have the later workflow check for information that would be added by the earlier workflow in a conditional in the form of a tag, then wait if that tag does not exist. This would hopefully give the earlier workflow the time needed to finish and then include the tag.
• Another option is to have the earlier workflow schedule the later workflow far enough in the future to ensure the earlier workflow has time to complete.

Above all else, design your workflows to avoid ordering dependency if possible.

Testing Transaction Verifications in Sandbox

In order to create a Sandbox verification for Transaction Workflows, make sure to use the Sandbox API key when you hit the Transactions API: Additionally, debug_forced_status is now exposed in the advanced config for the Run Verification step. Builders can set it to a Transaction field and mock pass/fail by setting that field when creating the Transaction.