In a previous blog post I covered case rules from a design perspective but I've recently heard from customers that I'm working with that they were still missing something which would allow them to implement those rules in a case project. What follows is based on a presentation I created to put some "flesh on the bones" of case rules. Straight up I'd like to thank my colleague Prasen Pavlankar... I've used screen-shots from some of his projects to help demonstrate some points.
If we remember from one of the earlier blog entries on the runtime lifecycle of a case management appication, the majority of events that happen within the context of a case can be caught and acted upon by case rules, a simple example being when a document is added to a case, a case activity can be initiated containing a human task to validate the document. As mentioned in the previous rules blog entry there are only a finite number of conditions and actions that can be caught and acted upon within case rules, I'll document all of these here....
There are only 7 basic ACM conditions....
...let's go through these one by one...
...as a decision table for example....
...or as a simple IF-THEN rule....
...as a decision table....
This applies to documents added at the level of the case via the CM API or added to human tasks which are part of processes exposed as case activities.
...as a condition table....
As a decision table....
...or more simply as an IF-THEN rule....
Although this is available I would counsel caution here. Comments are free-form text and can be added in an ad-hoc manner to a case.... implementing rules which simply act upon a comment being added could lead to unexpected results.
It is also possible to query the contents of the case data itself as conditions to a rule. For example, assume we only want to act upon a milestone being reached if the "claimant" element of our case data is "Joe Bloggs"....
Now that we have queried the conditions, what actions can we take ?
It is important to understand what is happening when we "activate" an activity. It is a slight misnomer as it just makes the activity available for invocation if it has been created as "conditionally available"....
...whether it is actually invoked or not depends on whether it is defined as "manual" or "automatic"....
Rule combinations can become fairly complex....
Use globals & bucketsets to define activity names, milestone names, event names etc... this will be provided out-of-the-box in an upcoming release....
Use functions to simplify decision tables....
Break up the rules into logical decision tables....
...as described in the previous case rules blog.
Case rules are an integral part of ACM, without them events that happen within the context of a case are more or less independent. Could you design an ACM project without rules, I think you probably could but it would be over-reliant on constantly querying the state of the case via the CM API. I think this is the nub of the problem with understanding case rules... the CM API itself is powerful and all-encompassing and it can be easy to fall into the trap of controlling too much of the lifecycle of the case from the API instead of allowing case rules to do a lot of the work. This is why I think the design of case rules is so important, it forces us to consider the relationships between case artefacts.