Customization of the Rule check-in approval process
The rule check-in feature allows you to use a process to manage changes to the application. Use this feature to ensure that checked-in rules are meeting the quality standards by ensuring a senior member of the team reviews them. Use this facility to control changes to sensitive applications.
Pega Platform™ comes with the Work-RuleCheckIn default case type for the approval process. The case type contains standard properties and activities and a flow called ApproveRuleChanges that is designed to control the rule check-in process.
For instructions on how to enable rule check-in approval, see the Community article on Configuring the rule check-in approval process.
When the default check-in approval process is in force for a ruleset version, the flow starts when a developer begins rule check-in. The flow creates a case that is routed to a workbasket. The standard decision tree is named Work-RuleCheckIn.FindReviewers returns the Work queues. Rules awaiting approval are moved to the CheckInCandidates ruleset.
By default, the review cases are assigned to a work queue with the same name as the candidate ruleset defined in the Work-RuleCheckIn.pyDefault data transform. Override the Work-RuleCheckIn.FindReviewers decision tree if you want to route to a different work queue based on certain criteria.
The approver can provide a comment and take three actions:
- Approve the check-in to complete the check-in process and resolve the rule check-in case.
- Reject the check-in to delete the changed rule and resolve the rule check-in item.
- Send back to developer to route the case to the developer and move the rule to the developer's private ruleset.
Affected parties are notified by email about the evaluation results.
You can enhance the default rule check-in approval process to meet your organization's requirements.
Rule check-in approval process for Branch rulesets
When using Branch based development, the individual rule check-ins have been emphasized less, as it is likely the review needs to happen on the entire change set that will be in the branch. Best practices for branch-based development would include:
- Ensure that branches are short lived, it should only be associated with the story of bug or user stories of a sprint, merge as soon as that work is done and reviewed
- Ensure that the changes introduced in the branch are off high quality, leveraging the branch quality landing page
- Review the entire change done in the branch - using the branch review feature
The rule check-in approval process in branch ruleset is not as relevant as in regular rulesets.
This Topic is available in the following Module:
If you are having problems with your training, please review the Pega Academy Support FAQs.
Want to help us improve this content?