A production ruleset is a ruleset that contains rules that you can modify after the application is deployed
The one in application rule form is optional field. If you specify your production ruleset here then the rulesets specified in this section needs also to be mentioned under the Access Group form's Layout tab
Where as for the access group level you need to enter production rulesets and versions specific to this access group. For example, in a production setting, you can identify one ruleset and version that remains unlocked and holds only rules expected to be changed often. Such rules can be delegated to management.
To my opinion, since one applicaiton has multiple access groups and not all access group requires the facility of saving delegate rules in production ruleset, so it is generally advisable to provide the production ruleset under the access group rather than Application
In my application, i have made some changes to web-login screen and created a new "unauthenticated" ruleset for the same. As per pega recommendation, we added that ruleset to a new "unauthenticated" access group as Production ruleset. This access group is added to BROWSER req type
We also made some changes to OOTB "pyChangePassword" section and used above mentioned ruleset so that they can be packaged together.
During testing, we realized that pyChangePassowrd screen is taking from Operators access group/application. In order for code to work for all user, we decided to add that ruleset as Production ruleset to Operator Application. But code does not work until it is added to each user's access group as well.
Quoting your line---" If you specify your production ruleset here then the rulesets specified in this section needs also to be mentioned under the Access Group form's Layout tab"
Is that correct? We will def be locking this ruleset. Could you please advise on this.
We want to keep the logic consistent since what we have developed could also be configured to other applications.