Hi everyone, 

Thanks for checking out the new "Change Management" feature!  Right now, we only support a few rule types - Decision Tables, Paragraphs and perhaps most importantly, Data Types.  (Any data type that is configured to be modified using the new record editor can be delegated, allowing business users to quickly make in-line modifications to data instances from their own portals).  Our goal is to quickly offer more business-facing rules in the near future.  (7.1.11, 7.1.12). When rules, Map Values, Decision Trees would be excellent candidates.  Sections and especially Activities would likely not be appropriate for your average business analyst.

Why did we make this architectural change?  Even though the old 'Favorites' model of 'delegation' supported any rule type, it came with a host of problems that caused confusion.  Opening a 'delegated favorite' using "My Rules" opened the entire rule in it's entirety, and customers rightfully complained that their business users had the ability to change anything they wished -  including rule availability, ruleset, ruleset version, etc. 

The second problem is that the experience was just plain poor.  A business analyst does not know (or care) what an 'Applies To class' is, nor do they care about any of the options offered in each rule's "Actions" menu. They shouldn't be exposed to all this technical jargon. They just want to make a quick change to some business logic in their app and move on.

The third problem is that the security' features that were implemented for rule delegation in the 6.x series completely broke when we moved to harness-based rules in Pega 7.  Take for example the Results tab of any Decision Table.  The options which govern whether the rows/columns can be modified, whether expressions can be used, etc... are controlled from this tab, and it allowed a developer to customize how a business user interacted with the rule during delegation.  In the 6.x series, only the first tab of a rule was rendered in the end-user portal, which effectively allowed us to hide all these switches on a tab we knew would not be accessible to the business line.  With the migration to harness-based ruleforms, the rule form is shown in it's entirety.  A business user can simply click over to this tab and re-enable something that should be turned off.

So it was with these issues in mind that we went about trying to "reboot" the concept of rule delegation.  The Mange Change delegation model solves these problems by allowing us to configure and associate different user interfaces that match the intention of the delegation.  Rather than a "one size fits all" approach of showing the entire ruleform, we can associate different user interfaces to the selected "intent" of a delegation.  Each dynamically sourced radio button on the delegation dialog can be associated with a unique  UI - for example, a UI that allows users to add/remove rows of a decision table vs. a UI that does not. 

This flexibility results in a dramatically improved user experience that we can control and customize based on customer use cases.  Indeed, our end-goal is for business users to not even realize that they are modifying a "rule".

To wrap up my long-winded response above, I would argue that although the list of supported rules is presently small, the architectural improvements introduced in ML8 are large.  Unfortunately the Actions > Delegate option is not yet turned on for Decision Trees.  You can use the old "favorites" mechanism until we roll out support for this later next year.