Pega Sales Automations FS (Cosmos) and CRM for FS compatibility
I recently created a new Pega Comos Application based on the following strategic applications (Application Stack):
- PegaSAFSCosmos - 8
- CustomerServiceForFS - 8.6
and it seems that this combination of applications does not work properly, in fact the "Create Operator" functionality of the Sales Automation application goes in error.
Does anyone know if there are known incompatibilities between these two OOTB applications?
Does Pega allows to use the two strategic applications together?
Accepted Solution
@ravi9779 - your observations are accurate in that CS is built on UIKIT and does not have theme-cosmos 'components' like preview and utilities panel etc.
However, the styles across these two design systems have been generalized such that it becomes easier to have the same data rendered in two different set of UI rules (by using "default" styles) and use the same process / flow rules.
To summarize, to render a case type 'owned' by one module into another module would require some rules in the integration rulesets as outlined in this article, patterns for which are shipped OOTB.
@AleMax225 CS is only supported on ui-kit - SA supports both ui-kit and Theme Cosmos
if you use both SA and CS - you want to use the uikit version
@RichardMarsot As per the SA 8.6 implementation guide located at https://docs-previous.pega.com/pega-sales-automation-implementation-guide/86/adopting-pega-cosmos-design-system cosmos can be used for Sales Automation even though the CS app uses UI-Kit. Can you please clarify? I want to make sure that I'm looking at the correct documentation for our current CRM implementation using CS and SA.
@ravi9779 A couple of things to note while making this decision of SAUIKIT vs SACosmos:
a) Core features of SA will be fully supported in both UIKIT and Cosmos versions of SA. However, starting 86, the SA product team is beginning to invest more in the theme-cosmos version of SA and hence one would observe all the latest enhancements going into this version and only selected enhancements to be made available in the UIKIT version.
b) There will be additional work involved in dev/test cycles for having the CS case screens on UIKIT render elegantly in SA theme-cosmos end user portals and vice-versa. The UI patterns for core case types are shipped OOTB and hence clients should be able to follow and extend the same and the expectation is the gains that clients would get by going with theme-cosmos version of SA in the long-run will outweigh the effort involved in getting the UI render in different design systems.
@NAGEV Hi Visu, thanks so much for providing those details.
"a)" is the reason why we are interested in adopting cosmos for our Sales Automation implementation
For b) - We are planning to implement the other way - render cosmos SA screens inside of CS UI kit, as our users will use CS Interaction Portal for both support and sales work. Supporting CS cases inside of SA is not in scope for at least an year from now.
However, I did a POC with my SA Implementation application having "PegaSalesAutomationCosmos" as the built on application and tried launching SA cases with in the CS Interaction Portal. This CRM app still renders SA screens in UI-Kit layouts, because the CS app doesn't have access to SAUI ruleset and CS app is built on PegaCRMBase, but not PegaCRMBaseCosmos.
This leaves me with the conclusion of adopting cosmos for SA will hold good if the client is using SAPortal(UserPortal in cosmos app) as a standalone portal. But cosmos benefits can't be realized for those scenarios of launching SA processes inside of CS Interaction portal, until CS is on cosmos design system.
Please let me know if my conclusion is wrong. thank you.
Accepted Solution
@ravi9779 - your observations are accurate in that CS is built on UIKIT and does not have theme-cosmos 'components' like preview and utilities panel etc.
However, the styles across these two design systems have been generalized such that it becomes easier to have the same data rendered in two different set of UI rules (by using "default" styles) and use the same process / flow rules.
To summarize, to render a case type 'owned' by one module into another module would require some rules in the integration rulesets as outlined in this article, patterns for which are shipped OOTB.