Using Rule Steps in a Flow
- Updated on 09 May 2013
- 5 minutes to read
Rule Steps evaluate a data input and return an outcome of true or false. This outcome path depends on how the input satisfies the conditions, that the rule(s) contain. Rule Steps can contain entirely original rules, or preexisting rules as long as they have been saved in a folder that is visible to the user. Rule Steps can be found in theSteps Tab, under the category Rules .
In this example, create a rule that evaluates all of the system's user accounts for these three conditions:
The Email address belongs to the "decisions.com" domain.
The Account status is active.
The 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.
TheRule 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 leaveIs 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 select 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 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 .
The condition we want to evaluate is whether the email address in question contains"decisions.com," so select the operator Text Rules > Contain s and click Next .
The value we're comparing against is "decisions.com," so in theInputs section of the next popup, enter "decisions.com" in theValue 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.
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 will find the anchor for this property under Account > AllowedIPList> Archived then, click Next .
The Archived 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 Archived property type, reword our condition as "The account's Archived 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 theArchived property, isActive is a Boolean variable that can only be true or false. When we reword our condition, we get "The account'sisActive 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.
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 Edit Input Mappings link in the Properties panel.
As required, map the Account object outputted byForEach Step 1 to [Rule] Name Rule' s expected input, and clickOK .
This completes our flow. It is now ready to test in the debugger, which can be accessed via the Debug Flow link.