skip to main content
Corticon Studio: Rule Modeling Guide : Advanced Ruleflow techniques and tools : Conditional Branching in Ruleflows : How branches in a Ruleflow are processed
 

Try Corticon Now
How branches in a Ruleflow are processed

Branch selection

Data is assigned to each branch before any branch execution occurs, so if an attribute in the branch condition changes value during a branch activity execution, it will not change the branch assignment. Further downstream, the new value is presented for subsequent branch activity execution.
Consider the following example. When branching by Customer.smoker, the value of smoker determines which branch is executed. Changing the value of smoker within a branch will not alter which branch processes the Customer.
Suppose you had the payload:
Customer 1 (smoker = "Yes")
Customer 2 (smoker = "No")
Changing the smoker for Customer 1 from "Yes" to "No" would not, within the current branch condition, cause it to be passed to the "No" smoker branch. Subsequent branching by smoker would use its current value.

Branching by associated attributes

When associations are involved, the data passed into the branch activity is the full association traversal of the branch condition. The entity (with possible associated parents) that satisfies the branch condition is passed into the branch activity. Child associations will be available during activity execution. Unrelated entities are part of the branch payload.
Consider the following example of branching by Customer.policy.type. All the policies for an order of some type will be passed into the matching branch.
Suppose you had the payload:
- Customer 1
- policy 1 (type="standard")
- policy 2 (type="preferred")
- Customer 2
- policy 3 (type="standard")
- policy 4 (type="preferred")
The branch for "standard" would be passed:
- Customer 1
- policy 1 (type="standard")
- Customer 2
- policy 3 (type="standard")
The branch for "preferred" would be passed:
- Customer 1
- policy 2 (type="preferred")
- Customer 2
- policy 4 (type="preferred")

Branch consistency

When a root entity is used for the branch and the branch activities use associations, care must be taken to ensure consistent results in a Ruleflow branch. It is important to use the same association traversals in the branch Rulesheets as used in the branch attribute. Thus, if the branch Rulesheets reference entities like Customer.policy.type and the branch attribute is on entity policy.type, the branch attribute in the branch container properties should be defined as Customer.policy.type, not Policy.type. If the branch container is the root entity Policy.type, the branch Rulesheets will still allow for references through the association Customer.policy.type to Policy entities that did not survive the branch.
Consider the following example of branching on Policy.type.
Suppose the payload had Policy.type:
- Customer 1
- policy 1 (type="standard")
- policy 2 (type="preferred")
- Customer 2
- policy 3 (type="standard")
- policy 4 (type="preferred")
The branch for "standard" would be passed:
- Policy 1 (type="standard")
- Policy 3 (type="standard")
The branch for "preferred" would be passed:
- Policy 2 (type="preferred")
- Policy 4 (type="preferred")
However in both branches, Customer 1 and Customer 2 (with associations) will also be available. So if rules in those branches reference Customer.policy, the rules will execute on every Customer.policy, not just the branched ones. Since the branch was on Policy, rules that reference Policy will only execute on the branched ones.