Rules and rule types
Rules and rule types
When you play a game of chess, you and your opponent agree to follow a specific set of instructions. These instructions govern gameplay, such as how each piece moves on the game board. For example, on its first move, the pawn can move one or two spaces forward. These basic instructions are the rules of chess.
When you model a case type in a Pega Platform™ application, you configure the application with instructions to create, process, and resolve a case. These instructions are rules. Rules describe the behavior for individual cases, such as how the user interface is displayed and when work urgency increases. Pega Platform uses the rules you create to generate application code in the background.
Each rule is an instance of a rule type. Pega Platform provides many rule types to use as templates for creating a rule. The rule type determines the type of behavior modeled by the rule. Each rule type models a specific type of behavior, such as automated decisions or UI design. For example, to model a process you use a specific type of rule called a flow rule.
Automated rule creation in App Studio
Much of the work of designing an application can be completed using App Studio. Pega Platform provides a simplified interface that automatically creates and manages the underlying rules while allowing developers to focus on business tasks. For example, when you configure a case type in App Studio, you use the case life cycle and configuration panels to add processes, define steps, and configure views. In the background, Pega Platform creates and manages the rules that define the process flows, tasks, and UI.
In the following image, drag the vertical line to see the case life cycle with a process created in App Studio and the flow rule of the process that is created in the background.
Application modularity with rules
The use of individual rules makes your application modular. By describing case behavior with modular, task-focused rules, you can combine and reuse rules as needed. For example, you create a rule to describe the content of a customer email regarding the status of a change of address. By creating the email message as a separate rule, rather than embedding the message in the case life cycle, you can update the content of the email without impacting the rest of the business process.
This modularity provides three significant benefits: versioning, delegation, and reuse.
|Versioning||Developers create a new version of a rule whenever case behavior needs to change. Pega Platform maintains a history of changes to a rule, allowing developers to review the change history and undo changes if needed. Because each rule describes a specific case behavior, the rest of the case remains unaffected.||For example, a developer updates a UI form with instructions and removes a critical field. You can review the history of the form and revert to the version before the changes were made, without changing other rules in the application.|
|Delegation||Developers delegate rules to business users to allow business users to update case behavior as business conditions change. The business user updates the delegated rule, while other parts of the application remain unchanged.||For example, expense reports that total USD25 or less receive automatic approval. You create a rule to test whether an expense report totals USD25 or less and delegate the rule to the Accounting department. The Accounting department can then update the rule to increase the threshold for automatic approval increases to USD50, without submitting a change request for the application.|
|Reuse||Developers reuse rules whenever an application needs to incorporate existing case behavior. Otherwise, you must reconfigure the behavior every time you need the behavior.||For example, you create a UI form to collect policyholder information for auto insurance claims. You can then reuse this UI form for property insurance claims and marine insurance claims.|
Check your knowledge with the following interaction.