In BPM it's common to create a framework BPM application and then create multiple Impl applications on top of it which are extensions of it.
My question is similarly how to create multiple marketing applications i.e one framework Marketing application and then multiple Impl applications. The problem I see here is the Cutsomer class. For marketing apps Work class doesn't have much significance, instead Customer class is the main thing which to my understanding as per pega marketing impl guideline can be only one i.e cannot vary for each application. In the application settings page we can define only one Customer Class , Artifacts rulesets etc, this application settings being a data instance can be only one which is being picked up Declare_MKTsetting declare page.
So I wanted is it possible to have multiple marketing applications (one framework and several Impls) each having it's own application settings , customer class/Table, artifact rulesets etc, if yes then how it can be achieved.
If multiple applications aren't possible then please throw some light what's the best way of implmenting the following
In our current project client wants to segregate rules and data of B2C and B2B between the respective teams. Now we thought that the best way of doing it is creating two seperate applications, however it is confirmed that's not possible.
Then how else we can do it ? should we use AR, ARO to do it, but that will not allow to open marketing artifacts belonging to other team , however they can see it in Marketing portal dropdowns, lists etc, just while opening or executing those they will see not authorized exception which isn't user friendly.
Another way is to customize entire marketing portal at several places to filter out rules belonging to other team etc, which will take lot of effort.
Please suggest what's the easiest way of doing it, any other way out.?
The only way to achieve this separation today is to provision multiple instances of Pega. If there is some form of sharing between these systems, you can potentially share some base rules, but have them deployed multiple times (one to each instance). The ability to support a single system with such separation is on our roadmap, but is not something that will be available in the short term.