In a Ruleflow, you often have steps which should only process an entity with a specific attribute value. You can accomplish this by using preconditions on a Rulesheet, but the resulting logic, or flow, is difficult to perceive when looking at the Ruleflow. The following Ruleflow shows a progression of processing from the upper left to the lower right. But the rules to decide whether a loan is approved or declined are one-or-the-other, and the Rulesheets for the US states do not really represent a progression because the applicant's state is going to trigger only one of these Rulesheets to fire its rules:
Looking at this Ruleflow the real flow is somewhat hidden. If the Rulesheets for Texas, California, Vermont, and Idaho each had a precondition such that only matching states were processed, then they represent a set of mutually exclusive options, not the linear flow depicted in the Ruleflow. We'll see how we can create a branch in a Ruleflow like this:
And then bring that Ruleflow into another Ruleflow where we will also create a branch for the Declined and Approved Rulesheets that also might have needed to use preconditions. The completed Ruleflow looks like this:
A branch node can be Rulesheet, Ruleflow, Service Call Out, Subflow, or another Branch container.
Note: Multiple branches can be assigned to the same target activity. These values are shown as a set in the Ruleflow canvas.
Refresher on enumerations and Booleans
Branching can occur on either enumerated or boolean attribute types. Only these are allowed because they have a set of known possible values. These possible values can be used to identify a branch. Using branches in a Ruleflow lets you clearly identify the set of options, or branches, for processing an entity based on an attribute value. In our example, using branching for the set of state options and whether the loan is approved or declined makes the flow more apparent. It will also be easier to create and maintain.
This topic covers general concepts of branching. First, let's review enumerations and Booleans as they are essential to branching definitions.
When defining elements of a Vocabulary, each attribute is specified as one of seven data types in the Corticon Vocabulary.
These can be extended by Constraints or Enumerations. In this illustration, States are extending their String type to be qualified as a list of labels and corresponding values that delimit the expected values yet offer the listed items in pulldowns when you are defining Ruletests. Notice that the Boolean Data Type is not listed as it is implicitly an enumeration.
The Vocabulary definition then chooses the States data type, a subset of String, as its data type.
Every attribute that is an enumerated data type or a Boolean is available for branching. For more information, see Enumerations in this guide.
