Using Rule Steps in a Flow

Last 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.

Example

In the example, we will create a rule that will evaluate all of the system’s user accounts for these three conditions:

  1. Email address belongs to the “decisions.com” domain.
  2. Account status is active.
  3. 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.

debugResult

 

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.

dragAllFlowSteps

 

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.

editRule

 

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.

 

 addNewInput

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.

nameRuleInputAccounts

 

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.

pickAccountTypeForRuleInput

 

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.

 

 addNewRuleStep

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 first condition of our rule is that the account’s email address must contain “decisions.com.” For our anchor data, select the input Account > EmailAddress then click Next.
 
 pickEmailAddress

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.

This completes our first condition. If we were to save this rule and use it as-is, only accounts with an email address containing “decisions.com” would be considered valid when inputted into this rule step.
 
 
 firstPartOfTheRule
Our next condition is that our account must have permission to access the portal. Click on the “(Add)” icon following the first rule statement and select Add Condition.
 
We’ll find the anchor for this property under Account > CanUsePortal,then click Next.
 
 canUsePortal

 

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.

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 Next.
 
 isTrue

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.

 

 ruleComplete

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.

Save and close the rule. Once the rule is saved, it is ready to use in our flow. All that’s left is to map our [Rule] Name Rule‘s input. Select this step and click the Show Mapping Editor link in the Properties panel.
flowConfigured
 

As required, map the Account object outputted by ForEach Step 1 to [Rule] Name Rule’s expected input, and click OK.

mappingToRule

 

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.

 

Additional Resources