Pega Core Concepts – Rule delegation
In this blog article, we will see how and why a rule can be delegated to the business users.
Before jumping into the delegation part, let me briefly explain the software life cycle from the developer point of view.
Consider any android application, we do see some updates happen periodically in certain time interval. Every update comes with a new feature and some bug fixes.
Say, Vodafone Customer Service department is using pega application.
This is how it all starts
- Vodafone department heads decide to use Pega as a technology to build their customer service application.
- RFP/Bidding occurs and Vodafone identifies the right vendor ( It can be any IT organization)
- The Vendor sets up the right team of developers, testers, operations engineers and start building the application.
- The application will be developed, tested and will be rolled out to production.
Production here refers to people in the Customer Service department. They are the production users who will start using the developed application.
Once the MLP is rolled out or released to production, then the development team can start working on the new features, improvements or bug fixes based on the requirements.
Then the subsequent production releases happen periodically.
We will focus on the 4th point.
Normally this release cycle spans 2 weeks to 6 months. It varies from different organizations and different methodologies.
Consider Vodafone organization, having three business policies.
All three policies are related to customers failing to pay the bill.
1. When the bill amount is higher than $100, then route the case to the special investigation department.
2. On 5th of every month send out a notification email to the customer.
3. On failing to pay, send out repeated emails to the customer.
When we see these requirements, we can implement them using different Pega rules and components.
This is just a high-level solution
1. When the bill amount is higher than $100, then route the case to the special investigation department. – I will build this requirement using decision rules ( decision tree, table etc)
2. On 5th of every month send out a notification email to the customer – Since this is time specific, I will build this using service level agreement (SLA) rules.
3. On failing to pay, send out repeated emails to the customer – to accomplish this, I will use correspondence rule to specify the email template.
Do you think these business policies stay the same forever?!
A big NO. Many factors influence change in these business policies.
So tomorrow, there may be some relaxation in the bill arrear amount, it can be increased to $150 or the business thinks it is wise to send out the notification at the start of every month also email template can vary based on the customer response.
The day after tomorrow, again these can be changed.
As I mentioned the release life cycle may vary from 2 weeks to 6 months.
Think about Vodafone organization using waterfall methodology where the production release will be once in 6 months.
To accomplish these requirements to production we have to wait for 6 months, but..but before that again the business policies may change 🤪 pissed off right.
That is why it is recommended to follow agile methodology where a release can be planned in short sprints.
Personally I am a fan of agile methodology, which can adapt to any change with a shorter release cycle.
Obviously Pega is built for change
What is rule delegation?
Rule delegation enables business users to update any business policies themselves without any developers involvement.
Let’s think from the developer’s point of view.
Things to note
1. A rule can be updated only when the ruleset is unlocked.
2. Whenever a new requirement comes in, the developer do the code changes in dev environment then do the testing in the testing and staging environment then finally it will go live to production.
In production, we cannot unlock any existing ruleset to update a rule. If you do so there are some chances that you may be fired 😉
But how about having a new ruleset, higher in the ruleset hierarchy, which can be kept open all the time so that any rule can be overridden? We can call it a production ruleset.
What are the risks involved in the production ruleset?
1. Any user who has access to production can open a rule and update the rule.
Solution: Have a separate access group so that the business users can only make the changes from their user portal. You can also have some approval flow for the changes.
But still in some unavoidable situation, we may be urged to save as some rule inthe production designer studio to fix production bugs. This is highly not recommended. I can still remember the old days when I used to do that!!!!
What are the prerequisites for delegating a rule?
We already know the answer.
1. A dedicated production ruleset
2. An access group for business users who can update the business policies. You can create a new access group or use some existing access group.
Step 1: Create a production ruleset – DelegatedRules
Records -> Sysadmin -> Ruleset -> Create new
Here you see a new ruleset is created.
I feel, there has been lots of confusion in using production rulesets.
How to use production rulesets?
You need to follow 2 things
a) Add the production ruleset in the application rule ->Advanced ->production ruleset array.
Open your application and add it.
To verify, after adding click on the operator profile to check the ruleset hierarchy
You can see the Added production ruleset – DelegatedRules in still NOT in the ruleset hierarchy.
b) Add the Production ruleset to the Access group
Now Open your current access group and add the production ruleset in the advanced tab.
Now save the access group and check the ruleset hierarchy from the profile.
You can see the production ruleset in higher in operator ruleset hierarchy
Important note: Always production rulesets should be added in the application rule and access group.
Step 2: Create dedicated access group for the business users.
Records -> Security -> access group -> create new
As a best practice, always create the access group name as <AppName:RoleName>
For now, I provided the manager role and save the access group.
In the advanced tab, add the production ruleset – DelegatedRuleset
Save the access group.
For testing purpose, you can also include a operator under the access group.
Okay, now let’s see how to delegate a rule.
What are the rules that can be delegated?
Pega doesn’t provide a list of rules that can be delegated and that cannot be delegated.
Normally the business rules like – decision rules, SLA, correspondence can be delegated to the business users.
Note: Business users may not have experience in pega development and may not able to handle complex business changes
How to delegate a business rule?
Step 1: Always remember, you should delegate the rule which is saved in Production ruleset.
Open the actual rule which has to be delegated. It must be in some application ruleset.
Step 2: Save as the rule in production ruleset – DelegatedRules.
Remember, you have to add the production ruleset in the application rule and access group.
Save and check the rule.
Step 3: Go to actions button and click on delegate.
Note: If you don’t have the option to delegate, then it means you don’t have the privilege to delegate. pxCanDelegateRules is the corresponding privilege. This privilege is default shipped with sysadmin4 roles. So an administrator access group can always delegate rules
Step 4: You have to specify 3 things
1. Delegate to access group – Specify the access group of users who can do the changes in business policies. In our case it is FirstApp:BusinessUsers.
2. Title – Specify the meaningful title
3. Description – This should explain in detail as a instruction to business users.
Click on Delegate. Now your rule is delegated.
Step 4: Login as business user.
On the left panel – click on the configuration icon.
You will see the delegated instance.
Step 5: Click on edit
This will open the delegated rule. You can edit and save the rule.
I updated the amount to $150.
Note: I added enable check out in the operator rule form and the delegated ruleset, that’s why checkout option is enabled.
Step 6: you can see the changes in the designer studio.
Open the decision rule DetermineInvestigation in DelegatedRuleset
How to promote the delegated rules to production?
1. Normally the production ruleset will be included in the product rule.
2. The delegated instance is a data instance under ‘System-User-MyRules’
To check go to app explorer and search System-User-MyRules
Click on the click name highlighted, you will see the instance.
You can click and open the instance to get the pzInsKey and include the pzInsKey in the product rule to move the rule delegation to higher environment.
I hope you are clear with the production ruleset usage and rule delegation.
What are the things to remember?
– When the release cycle is long, then it is highly recommended to use production ruleset.
– Have a dedicated production ruleset for delegation purpose
– Always add the production ruleset in the application rule and all the access groups so that the changes will reflect to all users.
– Delegate only the rules which are saved in delegation specific production ruleset.
– Use the Configuration option in manager portal and try to customize / mimic the same section in your application.
– To promote rule delegation to higher environment, don’t forget to include corresponding System-User-MyRules instance.
