The BPMN spec defines an intermediate rule event, which can be attached to the boundary of an activity (task or subprocess) to indicate an exception flow triggered when a "rule becomes true." Here a rule is defined as "an expression that evaluates some process data." I have never seen this used in practice, but even imagining where it could be used, it's not the way business rules are usually implemented in BPMS.
Let's count the ways in which BPMN's treatment of rules is strange:
- The most common use of business rules in BPMS is a decision service. That's like James's second example - customer credit is good or bad. In BPMN that would be modeled as a task (with a web service implementation). It has nothing to do with the rule event. In many examples used for descriptive modeling (i.e. no intention to drive an execution language like BPEL), the rule evaluation is implicit in a gateway. For example, a gateway might split paths for customer credit good vs bad, but the decision task (credit evaluation) is not even drawn... it's just implied. That's bad practice but very common.
- BPMN rule events refer, not surprisingly, to event-triggered rules. In BPMS these are less common than a decision service invoked by the process. Some BPMSs (e.g. Cordys, Pegasystems) use event-triggered rules to model constraints on runtime business objects. When instance data is inserted or updated, a business rule is triggered. The other place they're used is BAM, where the rule is triggered by an update to a performance metric or KPI, i.e. an aggregated measure of process data. But I know of no BPMS that uses BPMN rule events to describe this behavior.
- What seems to me would be a good use of the BPMN rule event might be response to an external event such as update to an external database or content repository. In these cases the external event is generated by the database or CM system, not by a "rule", so the rule event is not reallydistinguished from an intermediate message event... the normal symbol for an external event triggering an exception flow.
- The other interesting thing about a BPMN rule event is that the event must occur within the context of a particular activity (task, subprocess, or entire process) to have effect. For example, if the business event that would cause a "customer credit is bad" rule to fire occurs prior to the activity where the BPMN rule event is attached, it's as if the event never occurred. Also, the rule event's effect is to interrupt (abort) the normal flow of that activity and launch the exception flow. But this is just a subset of things business rules can do. For example, what business rule management calls a declarative rule might say simply "if A and B, then C", where C might just set the value of a variable. So BPMN rule events don't map well to declarative rules.