Using Rule Steps in a FlowLast Updated: 05/02/2018 Introduced in Version: 2.0
Rule Steps evaluate a data input and return an outcome of true or false. This outcome depends on whether or not the input satisfies the conditions of the rule(s) they contain. Rule Steps can contain entirely original rules, or preexisting ones as long as they have been saved in a folder that is visible to the user. Rule Steps can be found in the Toolbox panel, under the category Rules.
In this example, we will create a rule that will evaluate all of the system’s user accounts for these three conditions:
- Email addresses belonging to the “decisions.com” domain.
- Account status is active.
- Account has permission to use the portal.
Our example flow will display a form that lists the email addresses of all user accounts that meet the three criteria listed above.
We will begin our example with all of our flow steps already in place. Our flow retreives all user accounts in our system (with the step Get All step), creates an empty list that will contain valid email addresses (Create Data step), then iterates through our list of accounts (ForEach Step), sending each account to our rule step ([Rule] Name Rule).
[Rule] Name Rule evaluates each account it receives against the rule it contains. If the account is valid, the evaluation returns “True” and the email address of that account is added to our list in Add Item to List Step. If the account is not valid, the evaluation returns “False.” In either case, control of our flow then returns to ForEach Step.
If the ForEach Step has not reached the end of its list of accounts, it will send the next one to [Rule] Name Rule for evaluation. If ForEach Step has reached the end of its list, it will return the outcome Done, which passes control to [Form] list form. This form is where our list of valid email addresses will be displayed, along with a button labeled Done. Clicking Done will end the flow.
In our example, all steps except for [Rule] Name Rule have been configured.
To configure [Rule] Name Rule, double click the rule, and select Edit Rule.
The Rule Designer offers a simple but powerful interface for generating a data rule. As you’ll see in the next few steps, a rule is a collection of one or more conditions that must be met in order for an input to be considered valid. Together, these conditions form a statement that closely resembles plain English.
Before we create the conditions of our rule,we have to define the type of input that our rule can be applied to. In the Start Rule window panel, under the section Rule Input Data, click Add New.
In the Object Editor popup, define the input data as an Account object.
We want to evaluate each account individually, so leave Is list unchecked. We don’t want our rule to evaluate accounts that don’t exist, so also leave Can be null unchecked.
Select the Type selector.
In the Select Entity popup, define our input data as an Account object by searching for “account” in the search box, then selecting it, and clicking OK.
Back in the Edit object pop-up, click Save.
Next, define the conditions of our rule statement. In the Start Rule window tab, notice the rule statement has already been started with the word “If”
The “(Add)” icon in the Text Rule View tab indicates a point where a new condition (or condition group, which is covered elsewhere) can be included. Click the Add New Rule Step button to create the first condition.
Every condition consists of three parts:
- Anchor data (the input property which will be compared)
- An operator (the type of comparison being made)
- A value against which the input property will be compared
The condition we want to evaluate is whether the email address in question contains “decisions.com,” so select the operator Text Rules > Contains and click Next.
The value we’re comparing against is “decisions.com,” so in the Inputs section of the next popup, enter “decisions.com” in the Value field then click Close.
The CanUsePortal property type is a Boolean. To determine which operator we need for our condition, it sometimes helps to reword our condition using the available operator options. Based on what we learned about the CanUsePortal’s property type, reword our condition as “The account’s CanUsePortal property is equal to true.” We can find the operator that means “is equal” under the heading Logic > Is True. Click Done.
This completes our second condition.
Our third and final condition is that our account must be an active one. We’ll find the anchor for this property under Account > isActive,then click Next.
Just as with the CanUsePortal property, isActive is a Boolean variable that can only be true or false. When we reword our condition, we get “The account’s isActive property is equal to true.” We can find the operator for “is equal” under the heading Logic > Is True. Click Next.
Our rule is complete. Our three conditions are represented as simple statements that look very much like plain English, and clearly describe the total rule that must be satisfied.
As required, map the Account object outputted by ForEach Step 1 to [Rule] Name Rule’s expected input, and click OK.
This completes our flow. It is now ready to test in the debugger, which can be accessed via the Debug Flow link.