Every rule you build in Pega needs a home. That home is a ruleset.
If you think of rules as your source code, rulesets are how that source code gets organised, versioned and shipped across environments. Without understanding rulesets, you will struggle to make sense of how Pega manages its codebase at scale.
What Rulesets Actually Do
Rule sets serve three main purposes.
The first is packaging. Rules cannot float around without belonging to a ruleset. When it comes time to deploy your changes to a higher environment, you package the ruleset and ship it. Think of it like a JAR file in Java.
The second is version control. A ruleset can have multiple versions – zero one zero one zero one, zero one zero one zero two, and so on. You increment the patch version for small changes, the minor version for larger ones. This is Pega’s built-in version controlling for your source code – no dependency on Git or SVN needed.
The third is security. You can lock a ruleset so no one can modify it. You can lock individual versions while keeping the latest open for development. You can also enable checkout on a ruleset, which means developers have to explicitly check out a rule before editing it – similar to locking a file before making changes.
Application Validation vs Ruleset Validation
This is the part that trips people up, so let me keep it simple.
When a rule references another rule – say activity A calls activity B – Pega needs to know whether that reference is valid. The validation mode on the ruleset controls this.
With application validation, a rule can reference any other rule on the same application layer or any layer below it. It cannot reference rules on layers above it. This is the default and the recommended setting for most rulesets.
With ruleset validation, you have to explicitly declare which rulesets your ruleset depends on. If a rule references something in an undeclared ruleset, the design time validation fails and Pega will not let you save. This gives you tighter control but requires more upfront configuration.
In practice, most projects use application validation throughout. The ruleset validation mode is more relevant for organisational or component rulesets that are designed to be reused across multiple applications.
My recommendation – stick with application validation unless you have a very specific reason to use ruleset validation. Create a proper application layer for your organisational code and let the layer cake handle the resolution.
Watch the Full Walkthrough
In the video below I walk through the full ruleset configuration – versions, security settings, checkout options and a live demonstration of both validation modes in action.
Rule sets are one of those foundational topics that seem dry until you hit a validation error in a real project and suddenly everything clicks. This video will save you that confusion.
