Using Rule Steps in a FlowLast Updated: 02/12/2016 Introduced in Verision: 2.0
Rule Steps evaluate a data input and return an outcome of true or false depending on whether the input satisfies the conditions of the rule(s) they contain. Rule Steps can contain entirely original rules, or preexisting ones provided they has 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 the example, we will create a rule that will evaluate all of the system’s user accounts for these three conditions:
- Email address belongs 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 gets all user accounts in our system (with the step Get All 1), creates an empty list that will contain valid email addresses (Create or Copy Data 1), then iterates through our list of accounts (ForEach Step 1), 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 1. If the account is not valid, the evaluation returns “False.” In either case, control of our flow then returns to ForEach Step 1.
If ForEach Step 1 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 1 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, we will select it, which displays its Actions menu. Near the bottom of the menu are four options for editing our step. 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 an statement that closely resembles plain English.
Before we create the conditions of our rule, it is necessary to define the type of input to which our rule can be applied. In the Start Rule window panel, under the section Rule Input Data,click the Add New.
In the Object Editor pop-up, 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 pop-up, 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 pop-up, enter “decisions.com” in the Value field then click Close.
Notice in the pop-up that CanUsePortal is a property of the Boolean type, which means it can only be true or false. If the property is true, this account has permission to use the portal. If the property is false, the account does not.
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 in versions below 3.5, and via the Test Flow link in versions greater than 3.5. In the Form tab, we can see the email addresses for these accounts displayed in a single form field.