Question
Morgan Stanley
IN
Last activity: 27 Mar 2020 14:33 EDT
Should a production ruleset be added to the application ruleset stack
Hi
I have added a ruleset as a production ruleset in the application rule and by default the ruleset is not available in the operators stack unless we add it to the access group.
I din't understand why the production ruleset added is not added to operators stack by default.
Does this not cause any kind of inconsistencies in production env.. Since only a few users have access to rules in production ruleset while others dont have..
The usecase i'm talking is as below:
Lets say we have delegated a decision table for an operator.. The operator has access to production ruleset from an access group and also the ruleset is mentioned in the application rule. Now, in the application code i have written an activity to read from decision table to get some informaiton.
Now, user who has access to decision table is able to execute the DT. However, since i dont have the production ruleset added to AG its failing.
Should we add production ruleset to application rule rulset stack as well?
What is the recommendation?
***Moderator Edit-Vidyaranjan: Updated Platform Capability***
-
Like (0)
-
Share this page Facebook Twitter LinkedIn Email Copying... Copied!
CollabPartnerz
IN
Yes, we should add.
Pegasystems Inc.
FR
Hello,
When working with Production ruleset, I was mainly doing it via the AccessGroup. So this ruleset becomes on top of everything else.
I never had to add it on Application ruleset stack.
-
Robin Tijs Ravi Kumar Pisupati
Morgan Stanley
IN
That works fine for operators who are working on delegated rules. But what about the users who are dependent on the delegated rules.
I mean if there's an activity in app stack which makes use of a decision table which is part of production ruleset. Then the activity runs just fine for production ruleset added access group but fails for others.
How do we handle this scenario?
-
Nixon Philip Akash Vibhute Jose Navas
Pegasystems Inc.
FR
hello,
Well delegated rules is a different story I think. Your users either have access to Production ruleset or not. If not then they will have access to the default rule and not the delegated one.
Having said that, I might be missing your exact requirement.
Coforge DPA
IN
The Production rulesets that we mention in the Application rule form is just tells that what all production rulesets we have in the application. And in order to be available to end user they need to added to access groups and usually delegated rules and reports will be kept in production so that special users can amend if required.
COFORGE
GB
Thanks Naresh. I also came with same conclusion.
There is no dependency on rule execution with production ruleset configured in the application rule. If we add production ruleset in the Access Group then ruleset will be in the stack, no matter if it is configured in the application rule or not.
Short-forms used:
AG: Access Group
App: Application Rule
N: Not configured
Y: Configured
Rule delegated to super user access group.
Super User:
Scenario: 1
AG: N, App: N
Rule Opened from: app ruleset (able to checkout and checkin)
Scenario: 2
AG: N, App: Y
Rule Opened from: app ruleset (able to checkout and checkin)
Scenario: 3
AG: Y, App: Y
Rule Opened from: prod ruleset (able to checkout and checkin)
Scenario: 4
AG: Y, App: N
Rule Opened from: prod ruleset (able to checkout and checkin)
Case Worker:
Scenario:1
AG:N, App: Y
Rule executed from: app ruleset
Scenario:2
AG:Y, App: Y
Rule executed from: prod ruleset
Scenario:3
AG:Y, App: N
Rule executed from: prod ruleset
Thanks Naresh. I also came with same conclusion.
There is no dependency on rule execution with production ruleset configured in the application rule. If we add production ruleset in the Access Group then ruleset will be in the stack, no matter if it is configured in the application rule or not.
Short-forms used:
AG: Access Group
App: Application Rule
N: Not configured
Y: Configured
Rule delegated to super user access group.
Super User:
Scenario: 1
AG: N, App: N
Rule Opened from: app ruleset (able to checkout and checkin)
Scenario: 2
AG: N, App: Y
Rule Opened from: app ruleset (able to checkout and checkin)
Scenario: 3
AG: Y, App: Y
Rule Opened from: prod ruleset (able to checkout and checkin)
Scenario: 4
AG: Y, App: N
Rule Opened from: prod ruleset (able to checkout and checkin)
Case Worker:
Scenario:1
AG:N, App: Y
Rule executed from: app ruleset
Scenario:2
AG:Y, App: Y
Rule executed from: prod ruleset
Scenario:3
AG:Y, App: N
Rule executed from: prod ruleset
Please check runtime configuration and design time configurations significance in the access group.
Short answer is:
runtime configuration: user can access rules that are in the mentioned ruleset.
design time configuration: user can create rules from portal. Example: Reports (back end - report, category, shortcut rules will be created). This need ruleset should be configured in the runtime configuration as well.
Please check the below rule warning message:
Rule Type | Warning Type |
---|---|
Data-Admin-Operator-AccessGroup | Deprecated |
Name | ProdRSEntryNotInApp |
Message |
The Production RuleSet entry <RuleSet name> does not exactly match <RuleSet name>,defined in the Application <application name, application version> Future releases will not support this configuration. For details, see KB 25289 - How to configure production RuleSets and WorkPools. |
Details | N/A |
Severity | 1 |
Morgan Stanley
IN
Thanks everyone.
Thats where i'm confused. I understand that the delegated rules will be amended by privileged users. However, what purpose does it serve when these rules are not available to other users for access. i mean since we dint add the product ruleset to application stack these rules will not be available to other users.
Pegasystems Inc.
IN
Best practice is to add the Production RuleSet on the Application definition first, and then refer it in the Access Group. If we refer a RuleSet which is not present on the Application definition, you will see a severe warning on the AG rule form.
The production ruleset entry MyProdRS: is not defined in application MyApp 01.01.01. This configuration is deprecated. For details, see KB 25289 - How to Configure Production RuleSets and Work Pools.
CollabPartnerz
IN
Yes we can add
Coforge Limited
AU
For the delegated rules to be available to all access groups for execution, we need to add those in the application ruleset stack.
The production ruleset comes into picture when we want the operators to be able to create rules in production, mainly the customized reports. In this case, the operators with access groups having this ruleset in its production ruleset will only have access to this particular ruleset.
Raytheon Technologies
US
After reading this thread and all of the documentation I can find, the best practice on this is still very confusing.
Here's the scenario:
- An application has a production ruleset so that certain rules can be updated in production.
- Let's say we have a paragraph rule in the production ruleset that is delegated to the Managers AG so that Managers can update the content in production.
- We want all users of the application (regardless of what access group they are in) to execute the latest version of the rules in the production ruleset, everyone should see the latest version of that paragraph rule's content, regardless of what access group they are in.
What is the best option? Should we:
- Add the production ruleset to the Application rulesets stack in the Application Definition?
- OR Add the production ruleset to the Production Rulesets list (under Advanced > Run time configuration) in every Access Group
Option 1 seems like it would be easier to maintain and avoid the risk of having an Access Group that is missed. Are there any risks with option 1? Is there clear documentation to follow on this topic?
Morgan Stanley
IN
I could no where find any clear documentation as to what the best practice is.
I too agree with Option 1.
Optum
IN
The production ruleset section of the application does not make any change to operators ruleset stack.
This field only allows the listed rulesets to be selectable in access group that are part of that application.
Always add the production ruleset to all the access groups so that changes will be reflected to all users.
-
Trina Roy
Morgan Stanley
IN
Instead of adding it to all access group's I think adding it to the application ruleset stack is simple :)
Optum
IN
But adding them in the Production Rulesets in application rule doesn't make any change to the Operators Ruleset Stack.
T-Systems
MY
Please find my toughts to the scenario.
EX: Rulesets in Application A,B,C,D,P (where P is the production ruleset).
Operator 1 is having A,B,C ruleset access
Operator 2 is having C,D,P ruleset access
If the Production ruleset P is in Application Stack then Operator 1 and 2 can access the Rules in Ruleset P and only operator 2 can edit the rules in the ruleset.
Ernst & Young
ZA
When I click on the knowledge base article link quoted above I get "You are not authorised to access this page". Seriously?
Pegasystems Inc.
US
Hi @JohanH55,
The link here: For details, see KB 25289 - How to configure production RuleSets and WorkPools.has been archived as it was created in 2008 and references version 5.4 and below. Are you using version 5.4 or earlier?
I did a search on Rulesets on the Pega Community and this is the results. You can use the filters on the left to choose your version. If you do need versions prior to 7, please click the View Archive link at the bottom.
Thank you!
Marissa | Senior Moderator | Pega Collaboration Center
Ernst & Young
ZA
Thank you, but when I click the link I get this:
We are on 8.3. I'm just trying to find more information on production rulesets and delegation and all the posts I found were referring to that link. When I search through the community site I still end up with some 380 posts to wade through - most of which aren't even relevant. Not feasible. Not usable. Very disappointing I'm sorry to say. I wouldn't need to search if delegation was working as described in the documentation.
Pegasystems Inc.
US
I did a search on 8.3 but like you said it is still a lot of content to wade through. If you go to this search and click the Feedback button on the right, you can enter this feedback directly to our Pega Community team.
Are you looking for something specific that I could ask a Delegation SME to help you with?
Thanks!