Creating a Workflow

Overview

This tutorial will teach you how to set up a Workflow in the Sift Console. It will include an explanation of testing a new Workflow, and then moving the Workflow to production.

Workflows enable you to make risk-based decisions on users at your key decision points, like this:

Creating a Workflow

The steps involved in creating a new Workflow are the following:

1. Choose an abuse type, trigger event, and Decision entity
2. Choose whether you want to run the Workflow at every trigger event, or only when requested via API.
3. Create routes and set the business actions to be taken.
4. Enable your Workflow for testing.
5. Enable your Workflow for production automation.

1. Add new Workflow

To create a new Workflow in the Sift console, first navigate to the Automate Tab, and click “Add a new Workflow”, and name your Workflow.

2. Choose an abuse type

The next step is to choose the type of Abuse that this Workflow will prevent. The available abuse types are Payment Abuse, Promo Abuse, Content Abuse, Account Takeover and Account Abuse. If you need to make a Workflow that makes Decisions on multiple abuse types, please contact Support.

3. Choose a trigger event

The next step is to choose an event trigger. This dictates what key action taken by your customers will trigger this flow. Click on the dropdown to choose an event, such as “Create Order” or “Create Account.” These events correspond to the reserved and custom events you send Sift.

You can choose multiple events if the events have the same fields, for example you can have a Workflow that runs on both create and update order. This allows you to have one set of logic that is consistent for both create and update events.

Some events also allow you to apply a condition, for example on Transaction, you can decide to only trigger on successful transactions so that you don't make a Decision on a user until they have entered a valid payment method.

4. Choose the Decision entity

Now you will choose the type of Decision this Workflow will make. This can be any type of Decision entity you have, either User, Order, Session, or Content.

5. Choose the run type

The next step is to choose when you want this Workflow to run. There are two options:

1. Always: The Workflow will make a Decision every time you send Sift the trigger event. This is the default option.
2. Only when Requested: The Workflow will only Decision on a subset of trigger events, designated by an API parameter sent with the event (return_workflow_status=true or force_workflow_run=true). This is helpful if you want Sift to store and learn on all events, but you don't need to Decision on every single one. For example, if you want to prevent message spammers, you might run a Workflow the first time a user contacts a new user, but for every subsequent message between two users just send the event.

Once you’ve done this, click the button to create the Workflow and start building your routes.

Write Workflow Logic

Now you’re ready to add routes to your Workflow. Think of each route as a set of criteria that leads to some specific Decision (i.e. blocking an order, banning an account) or that sends a user/order to a review queue.

Adding criteria to a route

In order to add criteria to a route you’re working on, click the “Add Criteria” button. Choose some criteria that you wish to evaluate for this route. You can add multiple criteria to a single route. Criteria can be any field sent to Sift (reserved or custom), or the latest Decision that was taken on the user/order.

Adding an action to a route

Next you will choose the action that should be taken if the user/order matches the criteria of this route. This action could either add the user/order to a manual review queue, or trigger a Decision (actions that triggers Decision webhook notification to your backend).

Sending a User/Order to a review queue

You can choose the review queue to which you want to add this user/order in the dropdown menu. If you have not set up a manual review queue yet, or wish to create a new review queue, you will be able to through the “create a new queue” button. In order to create a review queue you need to fill in a few details:

• Name - The name of the review queue, such as “High priority chargebacks queue”.
• Timeout - This is a set amount of time that a user/order can sit in the review queue unreviewed before an automated Decision is taken.
• Timeout Decision - This is the automated Decision you wish to have taken if the user/order waits in the review queue for longer than the maximum time. For example you could automatically block any orders you do not have time to review, or you could automatically accept them.
• Available Queue Decisions - You can choose which Decisions are available to the reviewers in the review queue. For example the chargebacks review queue may have the “Block Order”, “Accept Order”, and “Request To Contact Support” Decisions available to it. A promotion abuse queue might have the “Ban Account” and “Request To Contact Support” Decisions available.

Once you have chosen all of these details, click “Save” to create your review queue.

Triggering an automated Decision

You can choose the “Set Automated Decision” button to choose an automated action that should be taken on the user/order which matches a specific route. Choose an existing Decision from the list, or create a new one by clicking the “Create New Decision” option. To learn how to create a new Decision, please read our Connecting Decisions to Business Actions tutorial.

Creating additional routes

To create an additional route, click the “add another route” button and repeat the steps above.

Setting a default action

In each workflow you must set an action that will be taken on any user/order who does not match any of the other routes. This can be sending them to a review queue or taking an automated action.

Connecting the Workflow output to your backend

In order for the Decisions you make in your new Workflow to be executed, you need to make some minor integration changes to consume the output of your Workflows.

If you want to consume the action that was taken by the Workflow synchronously, please read the documentation on Synchronously Requesting Flow Status and implement it on the triggering event for this Workflow. This is useful for time sensitive Workflows such as deciding to accept and order and process the payment instrument, or reject/hold it.

If you want to consume the action that was taken by the Workflow asynchronously, follow the instructions in the Connecting a Decision section of the Connect Decisions to Business Actions tutorial regarding webhooks. This is useful for Decisions that are taken by your operations team in our Manual Review Queues, or any action is not time sensitive.

Enabling your Workflow

Once you have tested your Workflow and are satisfied with the configuration, you can put it in action by choosing to 'Publish' the Workflow from the Edit view. Now your Workflow will be executed on every $create_order that is sent to Sift.

Testing your new Workflow

Initially when you enable your new Workflow, you may want to spend some time testing it and verifying that it performs the way you expect. In order to do this make sure that your Decisions, whether they are triggered automatically or by your operations team, do not actually execute the action but just log what Decision was made. This way you can see how many orders/users you will block/accept/etc. based on this Workflow.

Using your Workflow in production

Once you are ready to use your Workflow in production, connect the Decisions to actual business actions on your backend (Blocking/Accepting/etc.). You will now be automating with Sift!