Filters allow you to select which users will move on to the next step in a workflow depending on which queries they fulfill. To apply a filter, drag a filter node from the left-side tray to the desired location in the workflow. Filters are represented by purple nodes in the workflow.
There are several types of filters:
You can use the query builder to create your filters based on whether a list of users match certain profile fields or have certain events set on their profile. The interface is similar to the segmentation interface.
Below, we have added a query to filter on a field on the user profile.
We can also apply a filter that pertains specifically to the event that is triggering the workflow. In this case, we will need to flip the toggle. The filter below will only be applicable to a workflow that is triggered by a "completedTasteQuiz" event that has the data field "results".
Note: A race condition may occur if you are using a Fields Match node directly after a trigger node. For example, you may be triggering a workflow with a signup event; right after the trigger node, you have a filter that is checking the user profile for a certain field. However our system may not have had time to update the user profile before the user enters the field node. To account for the race condition, please add a 1 min delay after the trigger node before the filter node.
Dynamic Fields Matching Across Custom Events
Perhaps your company helps customers find and apply to multiple jobs. Or maybe you have an online clothing rental company that allows people to have multiple outstanding rentals at once. As a result, you need the ability to check if two events (e.g. job viewed and job applied or order shipped and order returned) have matching ids.
In this example, we are dealing with a business that helps people find their lost cats. The events we are interested in comparing are 'lostCat' and 'foundCat'. A person may have multiple cats that are lost at a given time.
The workflow is triggered with a 'lostCat' event. The user's 'lostCat' event payload looks like this:
However, the user may have multiple cats that are lost, and therefore multiple 'lostCat' events. In 5 days you want to check if there is a 'foundCat' event for the same cat (Lucifer) that first triggered the workflow. If the person has a 'foundCat' event with the same 'catId' as the triggering 'lostCat' event, then you want to congratulate them with an email on finding her cat.
Here's the payload for the 'foundCat' event that we're checking for:
By setting up the filter in this way, you will only send an email if the user has a 'foundCat' event with the same catId as the triggering 'lostCat' event. If the user finds any cat other than 'Lucifer', then she will get the congratulatory email for the other cat and not Lucifer.
If the field you are matching on is a numeric data type (integer, long, float, etc), be sure to cast the type of the field as a 'Merge Param'. This way, you can type in the curly braces for the merge parameter:
You can create multiple splits if you’re interested in testing different email series or delays. In the filter node, select ‘A/B Split’. You can create up to 5 splits and can specify the percentage split by dragging the allocation bar.
Using a Field Split, you can check if a user profile field matches up to 10 different values. Based on the match, you can route users to different parts of the workflow.
You can also include a default split for users who do not match any of the specified splits and route all of these users into a specified workflow.
If you do not include a default split and no matches were found for any available splits the user will exit the workflow.
For example, if you wanted to send a customized email template based on a user’s favorite color, you could apply a field split. If a user’s favorite color is not found or does not match one of the given choices, they can either be sent into a default path or if you uncheck include default split, they will simply exit the workflow.
Note: A race condition may occur if you are using a Field Split node directly after a trigger node. For example, you may be triggering a workflow with a signup event; right after the trigger node, you have a filter that is checking the user profile for a certain field. However our system may not have had time to update the user profile before the user enters the field node. To account for the race condition, please add a 1 min delay after the trigger node before the filter node.
For a complete overview of Iterable workflows, click here.