Rebuild the UX of an existing service request
One implementation design methodology is to rebuild the UX for a customer's existing service request. When using this methodology, you only change the UX of a service case. This process allows you to reuse most of the existing service request and keep the flow rules and flow actions intact.
This methodology involves rebuilding the UI/UX rules in a CME-specific ruleset to isolate the rules that Case Management Edition requires. You then add the ruleset to the implementation application stack to render the version of the CME service request. This process includes maintaining the UI/UX rules that you rebuilt in a separate ruleset so that there is a clear line of separation between Pega desktop and Case Management Edition. This process results in an easier implementation for Case Management Edition implementers and architects.
To implement this methodology, specialize and rebuild only the UX for the service requests to make them work with DX API and leverage the existing flow rules that you currently have in place. Save these specializations in a separate ruleset that includes only the UX specialization for some existing service requests.
Advantages and disadvantages of rebuilding the UX
The following table lists the advantages and disadvantages of using the Rebuild the UX design methodology:
|
Advantage |
Disadvantage |
|
Promote reusability of the flow rules for the Pega desktop or self-service channels that Pega Case Management Edition offers. |
The assumption is that you can reuse the service request and flow rules that exist today. However, this setup might not always be applicable. For example, this methodology might not apply when the implementations have very different flows for external desktop as compared to what already exists for the Pega desktop. |
|
Clear distinction between native UI and DX channels. Clients who leverage DX APIs add this new ruleset to the implementation application stack. |
Requires mock-ups and UX designs for the service request to be rendered by using DX APIs for both the non-Pega desktop and self-service. Implementation teams can refer to these designs when rebuilding the UX. |
|
Applicable for use cases where service requests might have a similar business flow in the DX channels than what exists in the Pega desktop or self-service. |
|
|
Guarantees an omnichannel experience because similar flow rules are applicable for the DX channel and other channels. |
|
|
No impacts to existing functionality in the Pega desktop because the changes for DX compliance are a part of a separate ruleset that is not part of the base application stack. This advantage applies only to those hybrid scenarios where you might be using a mix of Pega and non-Pega desktops. |
|
|
Low level of effort for the implementers. |
This Topic is available in the following Module:
Want to help us improve this content?