Rule Steps (Advanced)

Last Updated: 07/15/2016 Introduced in Verision: 2.0
Although it is easier to write simple rules (see Rule steps (simple)) for instructions on registering simple public bool methods as rules), you may want to take the time to write an advanced rule which allows more flexibility over how the rule is displayed in the rule designer and allows for custom design time validation, both of which provide for a better user experience when configuring the rule in the rule designer.
 
To create an advanced rule, create a public class and decorate with the  AutoRegisterRuleStep attribute. This attribute has four properties.
  • string name — This property sets the name of your rule which will show up in the rule designer.
  • System.Type anchorType — This property sets the type your rule will mainly interact with. This property is used to limit the rules that are shown in the rule designer based on which anchor data is selected for a rule statement. For example if you set this value to int32 your rule will not show up as a possible choice in the designer if you select a string as anchor data.
  • bool anchorTypeIsList — Similar to the anchorType property, this property is used to limit which rules show in the rule designer based on the anchor data selected. However, this property limits the rules shown based on whether or not the anchor data is or isn’t an array.
  • params string[] categories — This property sets a category in which your rule will be displayed in the rule designer
Here is an example showing how to decorate your class.

The previous decorated class would show up in the designer looking like the following:

 stringHasValue
 
 
After decorating your class with the  AutoRegisterRuleStep attribute, configure your class to inherit from AbstractRuleStep. This interface provides a default implementation for all the methods of the  IRuleStep interface. You can customize these default implementations by overriding them. The following examples show how to override the most common methods.
 
The first method you will want to override is the  Run method. The default implementation of this will always evaluate  false. The following example snippet shows how to override the  run method to evaluate if the anchor data is not null or empty

 When used in the rule designer, this rule would look like the following when configured to evaluate  Flow Data.InitiatingUserEmail as the anchor data. Notice how the rule has no description of what it is doing. This description, or rule verb, will be demonstrated next.

 
 secondScreen
 
Next you will likely want to give your rule a “verb.” This verb is used by the designer to describe in sentence form what your rule is doing. To give your rule a verb, override the  GetVerbInfo method as follows.

 

This configuration would show up in the rule designer looking like the following

 userEmailHasValue

 

The above sampled rule has no input data because it is only evaluating whether or not the anchor data has value. However, there are many times when a rule needs to have input data (see: Flow Steps and Rule Steps (Advanced) : Consuming Data for more on adding input data to your rule). In cases where your rule has input data, you will want to also override the  GetValueInfo method to format how this input data appears in the text of your rule. The below sample code shows an example of input data and how to format this data to show up nicely in the rule designer.

 

The above configuration would render like this before selecting input data:

 equals
 
 
The above configuration would render like this if value was configured to “tom@decisions.com
 
 equalsWithEmail
 
In addition to input data, you may also want a rule to have a property. The following example shows how to construct a rule with a property value. This rule evaluates the length of a string to see if its length is less than a number property.
 
The property of the rule would be written like this:

 

and the run method would use the property like this:

 This property would show up in the rule designer as a value that can be hard coded. It looks like this.

 lengthLessThanOne
 
 
We may also want to add some design time validation to our rule which would prevent the user from entering a number value less than 1. To do this, you will need to configure your class to inherit from and implement the  IValidationSource interface. You’ll also want to add  InvalidateVerbInfo(); to you property’s set so that the validations show up correctly in the designer when the value of your property is changed. The property and implemented  IValidationSource would look like the following.

 

This design time validation would show up looking like this.

 
 lengthMustBeGreaterThanZero

Additional Resources