Interaction Portal UX and upgrades - What can I change?
|Description||UI and UX guidelines for Pega Customer Service 8.5|
|Version as of||8.5|
|Capability/Industry Area||Strategic Apps|
This design pattern guides consultants and customers on making decisions about Interaction Portal customizations, specifically, which areas of the screen they can customize and which areas to leave alone in order to ensure that the next upgrade isn't a headache.
Use case examples
You've been asked to make a change to out of the box UI in the Interaction Portal. Arming you with an answer as to whether that Is advisable, supportable and upgradeable is the goal of this article. Essentially if it isn't supportable or upgradeable - it won't be advisable!
Before you begin
Take a look at the requests you are getting and do a self-assessment on likely upgrade risk. While most UI sections are either final or marked as extension points in Pega Customer Service 8.5, given the number of rules in the system, exceptions will apply. Being aware of whether something can be done without a final rule override is probably a good start but the following questions should all be considered when asking yourself the question of whether a change is advisable or not.
Does the requirement:
- Require you to attempt to override something marked as final?
- Require you to override a section that isn't marked as final but would be called out as a CS Guardrail warning? (Pega Customer Service 8.5 or newer releases)
- Require you to fundamentally change the behavior of a UI component in the CS distribution not marked as final, but move it away from the behavior that came with the out of the box control?
- Change the general screen layout, navigation or tab behaviors in the Customer Service portals?
Not a big list to consider, but a list where a few examples will help illustrate the potential issues. If you are considering UI changes that match items on the previous list, reconsider or look for alternative solutions before implementing. In the majority of cases, the cost of the work isn't just the opportunity cost of doing them, but the much bigger cost of upgrading and maintaining them over time if you've changed something fundamental in the product that subsequent releases will not support.
The following examples should be familiar to you if you have some experience with older versions of Pega Customer Service.
Screenpops are a common areas where we see overrides, some good and some bad (as measured against the list above). Generally, feel free to change any of the content of the screenpop, such as the identity of the contact (if known), whether the contact is verified, and the contact data that you want your Customer Service Reps to see prior to the interaction. Don’t customize the dimensions of the screenpop or the channel and buttons. In the future, if we want business users to be able to change those elements, we will make them editable in App Studio.
Service action area
The service case is another area where customizations are performed and sometimes fail the evaluation criteria we outlined above. Sometimes those changes are due to out-of-date knowledge about the capabilities of the product. A lot of focus on the product over the last few years has been to remove the need for customizations in Dev Studio. For example, it's possible to remove dialog from service cases through a simple checkbox configuration in App Studio, rather than overriding the section rule to remove the UI. Removing dialog through the configuration not only removes the display, it removes calls to the server and it removes the I/O of that data being requested from the database. Making this change through a section rule only does not remove the calls or I/O. Modify the contents of the case, but do not modify the case headers and buttons that progress the case.
While there are a multitude of ways to create a service case, the best practices for doing so have changed drastically in Pega Customer Service 8.5. While Dev Studio still allows you to tweak UI sections and harnesses (perform, review and confirm), 8.5 introduced case type templates to App Studio, removing the need (or in some cases the possibility) of tweaking UI – given that views are heavily mandated. In preparing for the Cosmos Design System, we recommend that you use case type templates to create new service cases and that you rebuild existing case types to use case type templates. The Cosmos Design System will not include UI sections and harnesses, since many UIs will be automatically generated, so do not spend time on harness customization.
Headers and tabs (and interaction drivers)
Another area where new best practices are available is in the part of the UI that is specific to channels and navigation aids. While some were App Studio configurable in earlier releases, in 8.5 all channels and tabs are configurable through App Studio. If you have new tabs that populate the portal with information from external apps, supported extension points are available for that use case.
The interaction driver is another part of key supporting functionality that occasionally gets customized. As the following warning illustrates, the new CS Guardrails list is keeping a vigilant eye on the location of specific customizations that are not advisable and certainly are not expected to be upgradeable. Keep an eye on CS guardrail warnings, as they are focused (and will continue to be focused) on upgradeability focused issues.
Making supported changes to the Interaction Portal UI
See any patterns in the examples above? One pattern that stands out is the difference between content and structure. You can change the content, but you should not change the structure. That’s a bit of a mindshift from 7.x and earlier releases of Pega Customer Service where the application was more open, and there were few restrictions on what changes you could make.
A rough analogy to help illustrate the point is modification of a house. Change the house color, change the contents of each room, add that shower to the half bath if needed, but don’t expect to add a basement to an existing house without a lot of pain and cost because the architect never designed the house (or its foundations) with that need in mind!
If it doesn't pass the advisable, supportable and upgradeable sniff test, don't implement the UI change.
Following this design pattern gets you up to date on areas of UI customization that are supported vs ill-advised. It provides guidance on changes to the UI architecture in the 8.x series of releases, and sets you up well for new design patterns coming in newer Cosmos design systems in the coming months and years.