Question
Adqura
IN
Last activity: 10 Feb 2021 11:46 EST
Group Leevel Strategies are not generating in NBAD framework
In the NBA designer framework, we have created the Taxonomy as Issue=Sales and Group=CurrentAccounts. Then added a sample action under this group. Enabled both Issue and Group from Taxonomy screen and configured basic constraints, engagement policy and submitted the schedule.
Expected result: We are expecting the group level strategy to have all the relevant components as per the framework starting with import of propositions and passing through the PF's and sub strategies. But the generated strategy has only 2 set property components namely Relevance and Best Result both connected to the result shape.
Is there any other configuration to be made so that the generated strategies will have all the required components?
The version we are using is 8.4.3. 
Updated: 2 Feb 2021 17:57 EST
Pegasystems Inc.
US
Hello!
In order to help you as best as I can, I do need to ask a few questions and check a few boxes.
- Are you using version 1 or 2 of NBA Designer? I can infer that it's version 2 based on some of the terms you've used, but I want to confirm, as this answer is important to understanding what may be happening behind the scenes.
- Is the ruleset that contains the backing strategy (AppsFW-CampaignsOutput:01-01-01, from what the screenshot is showing) the ruleset defined as the default destination ruleset on your user's access group (on the Advanced tab)
- If so, is that ruleset unlocked?
- Along the same lines, is there another version of that strategy in a different ruleset than the one you've shown?
- Did you encounter any errors when saving the engagement policy, either in NBA Designer or in the logs?
- If you save the CurrentAccounts group engagement policy again, does the backing strategy update as expected?
I think these questions will help us begin to narrow down what may be happening in your situation.
The strategy you've shown is representative of the placeholder configuration we generate during initial framework creation. When you save the group level configuration (engagement policy), I would have expected the backing strategy to have been updated with more complete logic. This suggests to me that an error may have been encountered surrounding strategy updates.
Hello!
In order to help you as best as I can, I do need to ask a few questions and check a few boxes.
- Are you using version 1 or 2 of NBA Designer? I can infer that it's version 2 based on some of the terms you've used, but I want to confirm, as this answer is important to understanding what may be happening behind the scenes.
- Is the ruleset that contains the backing strategy (AppsFW-CampaignsOutput:01-01-01, from what the screenshot is showing) the ruleset defined as the default destination ruleset on your user's access group (on the Advanced tab)
- If so, is that ruleset unlocked?
- Along the same lines, is there another version of that strategy in a different ruleset than the one you've shown?
- Did you encounter any errors when saving the engagement policy, either in NBA Designer or in the logs?
- If you save the CurrentAccounts group engagement policy again, does the backing strategy update as expected?
I think these questions will help us begin to narrow down what may be happening in your situation.
The strategy you've shown is representative of the placeholder configuration we generate during initial framework creation. When you save the group level configuration (engagement policy), I would have expected the backing strategy to have been updated with more complete logic. This suggests to me that an error may have been encountered surrounding strategy updates.
It may be helpful to run a tracer session while saving the group level engagement policy to see if any errors are encountered. This could be a general trace, though you may also be able to have a more targeted trace if you trace the SaveConfig activity in the Rule-PegaMKT-NBA-Config class.
NBA Designer has a very complex architecture backing it, but I'm confident that we will be able to figure out what's happening here once we can narrow things down a bit more!
- Josh
Adqura
IN
Thanks for taking time to respond. Below are the answers for your questions.
1. About the version 1 or 2: I came to know about different versions when I can trying to fix the legacy mode issue earlier. https://community.pega.com/knowledgebase/articles/pega-marketing/migrating-context-dictionary-legacy-mode-standard-mode
Thanks for taking time to respond. Below are the answers for your questions.
1. About the version 1 or 2: I came to know about different versions when I can trying to fix the legacy mode issue earlier. https://community.pega.com/knowledgebase/articles/pega-marketing/migrating-context-dictionary-legacy-mode-standard-mode
- Step 8 from this article mentions about migrating to version 2 which I though is mandatory which gave me another link https://community.pega.com/knowledgebase/articles/pega-marketing/upgrading-next-best-action-designer
- I followed the steps in the second article to migrate to Version 2 but I didn't get the "Upgrade" button on the NBA Designer screen after re-login.
- I am not 100% if I am on V1 or V2, is there a way to verify it? Below is my Designer screenshot..
2. Ruleset: Yes AppsFW-CampaignsOutput ruleset is configured as default destination and is unlocked. I can see 2 versions of the strategy in the system one is in ADQURA-FW-AppsFW-Data-Party the class configured in the context dictionary and one in Data-Decision-Request-Customer class.
3. I don't see any errors when I edit and save the taxonomy for issue and groups.
4. Tried multiple times, but the background strategy is not getting updated.
Pegasystems Inc.
US
Well this is an interesting situation.
Ok, so first of all, the UI you've shown in the screenshots is representative of Version 2 of NBA Designer. It's not labeled as such explicitly, but it is significantly different from Version 1 in presentation and behavior, so there is no mistaking it. We can confirm this now.
I have a few more follow-on thoughts to see if we can understand this better.
My understanding is that your application was previously in Legacy mode, so you took actions to address that. You then took the steps to update NBA Designer, as it would be required.
It's odd that you would not have seen the upgrade button if you configured the "MKTEnableNBADversion2Upgrade" dynamic system setting as described. The visibility of the upgrade button is based on a couple of factors, including that dynamic system setting. If we assume that visibility is the issue:
Well this is an interesting situation.
Ok, so first of all, the UI you've shown in the screenshots is representative of Version 2 of NBA Designer. It's not labeled as such explicitly, but it is significantly different from Version 1 in presentation and behavior, so there is no mistaking it. We can confirm this now.
I have a few more follow-on thoughts to see if we can understand this better.
My understanding is that your application was previously in Legacy mode, so you took actions to address that. You then took the steps to update NBA Designer, as it would be required.
It's odd that you would not have seen the upgrade button if you configured the "MKTEnableNBADversion2Upgrade" dynamic system setting as described. The visibility of the upgrade button is based on a couple of factors, including that dynamic system setting. If we assume that visibility is the issue:
- Please double check that the MKTEnableNBADversion2Upgrade dynamic system setting is properly configured exactly as the guide suggests (capitalization, spelling, ruleset, value, etc), just to check that box.
- Presuming that check outs, it suggests one of two things may be happening from the technical side of the scenario:
- Your operator may not have sufficient privileges to manage NBA Designer. This seems unlikely, but it would be helpful to confirm that the HasPrivilegeToManage When rule in the Rule-PegaMKT-NBA class would return true for your operator. Put slightly differently, at least one role on your Access Group should have the "CanManageNBA" privilege.
- Somehow the MKTUpgradeToNBADVersion2InProgressNBA dynamic system setting may be set to "true" when it shouldn't be. This would also prevent the button from appearing as anticipated.
For additional context:
- Did you have a version of NBA Designer prior to 8.4.3, or is this a new implementation?
- Do strategies for other group engagement policies generate as expected? Or is the behavior the same?
- Have you tried making a change to the engagement policy? For example, Edit, add an eligibility condition, and then save?
Adqura
IN
Please find the response inline.
- Please double check that the MKTEnableNBADversion2Upgrade dynamic system setting is properly configured exactly as the guide suggests (capitalization, spelling, ruleset, value, etc), just to check that box. @anand: Verified, all OK
- Presuming that check outs, it suggests one of two things may be happening from the technical side of the scenario:
- Your operator may not have sufficient privileges to manage NBA Designer. This seems unlikely, but it would be helpful to confirm that the HasPrivilegeToManage When rule in the Rule-PegaMKT-NBA class would return true for your operator. Put slightly differently, at least one role on your Access Group should have the "CanManageNBA" privilege. @anand: Have tested the when rule with my operator, it returned true
- Somehow the MKTUpgradeToNBADVersion2InProgressNBA dynamic system setting may be set to "true" when it shouldn't be. This would also prevent the button from appearing as anticipated. @anand: This one is set to false
For additional context:
Please find the response inline.
- Please double check that the MKTEnableNBADversion2Upgrade dynamic system setting is properly configured exactly as the guide suggests (capitalization, spelling, ruleset, value, etc), just to check that box. @anand: Verified, all OK
- Presuming that check outs, it suggests one of two things may be happening from the technical side of the scenario:
- Your operator may not have sufficient privileges to manage NBA Designer. This seems unlikely, but it would be helpful to confirm that the HasPrivilegeToManage When rule in the Rule-PegaMKT-NBA class would return true for your operator. Put slightly differently, at least one role on your Access Group should have the "CanManageNBA" privilege. @anand: Have tested the when rule with my operator, it returned true
- Somehow the MKTUpgradeToNBADVersion2InProgressNBA dynamic system setting may be set to "true" when it shouldn't be. This would also prevent the button from appearing as anticipated. @anand: This one is set to false
For additional context:
- Did you have a version of NBA Designer prior to 8.4.3, or is this a new implementation? @anand: We are doing a POC on exploring the NBAD capabilities. We had one more environment earlier where it worked. The difference between that and this env is that one is upgraded and other is direct installation of 8.4.3
- Do strategies for other group engagement policies generate as expected? Or is the behavior the same? @anand: The behavior is same for all groups that I tried.
- Have you tried making a change to the engagement policy? For example, Edit, add an eligibility condition, and then save? @anand: Yes I added a sample engagement and contact policy and also submitted the schedule on the last step Channel screen of NBA designer.
Pegasystems Inc.
US
Thanks for all the information!
Hmmm, this is interesting.
Are any PegaMKT rules overtaken in your own rulesets? It's possible that there is an overridden rule that is preventing the upgrade panel from becoming visible.
Is the production level of this system set to represent a production system (level 5)? You can test that by running the IsSystemInProduction When rule. If it returns true, you will also not see the upgrade panel.
- Josh