Rules, Workflows, and Platform Customization
Rules are typed contracts
Rules are BeanShell snippets stored as first-class objects and referenced from configuration. Each rule type has a defined input context and an expected return value: an identity attribute rule returns a value, a correlation rule returns an identity, a build-map rule returns a map for connector arguments, a provisioning rule returns a result, a policy violation rule returns violation objects. Getting the return type wrong is the most common failure, and it usually surfaces as a null or a class cast rather than a clear error. Shared code belongs in rule libraries rather than copy-paste, and rules should log through the provided logger at an appropriate level instead of printing.
Workflows
A workflow is a set of steps connected by transitions: start, approval, provisioning, subprocess, and terminal steps, plus forms that define what an approver sees. Variables carry state, and persistent variables survive across steps. Workflow cases track running instances and are the first place to look when an approval never fires.
Traps
- Editing a rule that is referenced by XML but forgetting to import the updated object.
- Assuming a workflow step runs as the requesting user; execution context matters.
- Catching exceptions broadly inside a rule so genuine failures never reach the task result.
- Hardcoding identity or application names instead of resolving them from arguments.
Rule of thumb
Write the smallest rule that returns exactly the expected object, log inputs on failure, and move anything reusable into a rule library.