Switching portals and access groups in Constellation
Enjoyed this article? See more similar articles in Constellation 101 series.
Why
Pega provides numerous configuration options for Users (Operators), including the ability to configure multiple access groups, portals and landing pages. In Traditional UI, an ability to switch between Portals and Access Groups was provided to users in their portals (run time).
In Constellation the prescribed best practice is to provide your user with a unique Persona (Access Group) for each of their applications.
In this post
- We explore this best practice in detail: the Pega building blocks of providing a user access to the system and how this provides a better experience for everyone the Pega community; users and developers.
- Different approaches to extending this capability: How you might want to extend or customize Pega to provide launch portal like capabilities. Understanding the caveats and long term maintenance costs it may introduce.
Purpose and functionality
- Portal - An end users interface into the application - what they see when they login. It is the landing pages on the left hand-side, the create menu, logo, header and search.
- Persona - Represents a type of user for your application, defined by business role and the resulting responsibilities in a business process.
- Access Group - Represents a group of privileges in the system. Every time you create a Persona, an Access Group is created in the background. Every time you manage that persona's access in App Studio and Dev Studio wizards, the Access Group is updated.
See more detailed documentation on Understanding Personas and access management.
Business use cases
In a Business context, the Persona is everything. It controls what you see when you login, what landing pages you have, what you can run Insights on (reporting) and what actions you can take inside of a case.
The consequences of getting this wrong have a huge impact. Users can't find what they need to do their job, features are hidden, bugs can creep in and generally they find the system unusable.
On the other hand, get your Center-out™ business architecture correct and users can do their job and all this configuration is seamless.
Constellation mindset
Minimize settings to maximize value
Transitioning to Constellation involves a shift in mindset from customization to configuration.
Constellation is a whole new UI authoring experience. Constellation applications offer quicker time to value, easier upgrades, and an out-of-the-box UI with accessibility improvements built in. To take advantage of these benefits, you must embrace Constellation’s configuration paradigm.
Simplified authoring
In traditional architecture, we generally built these elements from the ground up, from the rule itself. Roles, Access Groups, Portals, Harnesses and Sections. A skilled developer could navigate these with ease, however, less experienced Pega resources could find this authoring difficult to navigate, introducing the risk of configurable a poor user experience or even bugs.
Since early in the Pega 8 series, new features have been slowly introduced to make this configuration easier and easier. In Constellation '24 (and soon '25), this authoring in this space really comes into its own.
Personally, I almost never dip into any of the afore mentioned rules directly, the various configuration wizards provided provide more than enough control to configure what I need.
Configuring excellent user experiences in Constellation
1. Persona Management
Personas are a design tool that helps you group users according to the responsibilities that they assume within a Process, the Cases on which they work.
This grouping provides for a more granular level of control over the user experience, from defining which Stages of a Case belong to which type of user, to customizing the interface to include only the information that a specific role requires.
App Studio, and Blueprint, provide an easy way to create new Personas
- In App Studio, go to the Users menu > then User Management. This menu is currently not available in Dev Studio ('24.2 at time of writing).
This importantly, creates you the basis for further configuration in App or Dev Studio.
Best practice: Create new personas
Create a persona for all your business roles and functions.
You can create as many personas are you like. This is our primary way of ensuring the end user is delivered exactly the functionality they need.
Traditional UI mindset - the downside
In the past creating a new Portal and the various Harnesses (landing pages) needed in Dev Studio, this was time consuming and required skilled resources. As a result, this tended to result in "less configuration approach" - in our scenario a team leader was given access to a User and a Manager portal instead of providing a curated experience for the team leader. It was easier to do and reused existing assets.
This was great for developers but not so great for our users.
No user wants to click around trying and find the features they are after.
- This "switch portal, switch access group" approach resulted in really poor end user experiences. I've lost count if the number of bugs where I've seen this feedback from real users.
- The number of times sat in user testing sessions watching people try and figure out how to find the list of things they need to approve or manager functions to change settings. In my head screaming, "click your operator to switch to the manger portal".
Switch portal is a great concept for developers but to users in our systems, this just is not intuitive.
Imagine having to do this in our ever day lives:
- You have two email accounts, one to read emails and one to reply to emails
- You have two banking apps, one to read your statements the other to send payments
- I have to approve my access to my work email on laptop using an app on my phone every time
These are some extreme, and not so extreme examples. This illustrates how having to switch, or having to find out how to switch, just to do your job (your persona), provides us with frustrating end user experiences.
2. Portals and Landing pages
This can be accessed from App Studio or Dev Studio - defining the user experience for this portal.
- Application name (top) > Channels and interfaces menu in Dev Studio
- Channels menu (left hand side) in App Studio
Landing pages
This wizard allowing you to quickly creating new landing pages. I can't stress how much the authoring experience here is improved over manually editing harness rules and action sets in Traditional UI.
Configuring the Portal
Configure the experience for this portal:
- What can we create
- What landing pages should we access
- Branding and theming
- Search and other portal features
Good practice: Create a Channel for each Persona
For those coming from Traditional UI, this can difficult. Let me try and explain, Constellation unlocks many advantages of Traditional UI rules based development.
- Landing pages are easy to create and configure
- Channels are easy to create and configure
- Allowing you to group the exact landing pages a person needs to perform all of their functions of their role. This includes the ability to reuse landing pages across your channels
- Channels have features which tend to have variation between personas:
- A user should not be able to search the application, a manager should
- An auditor should see these 5 cases to create, but an applicant should only have 1 case to create.
- In fact, if you create the applicant their own portal/landing page, you can give them Constellation Quick links feature to make this even more prominent
Quick links widget on a landing page to create cases
- In fact, if you create the applicant their own portal/landing page, you can give them Constellation Quick links feature to make this even more prominent
Build for Change®
Business change and evolve, so do their asks for individual personas of their application.
By giving each persona their own unique access group and own channel you set yourself up for flexibility to change as those requirements evolve. Projects requirements evolve:
- We start with a "user" and "manager" persona, giving "team leaders" the ability to switch between both
- A requirement comes along 3, 6, 9 or 12 months later, where we have to introduce a new Persona (Access Group), or implement even more complex when rules, visibility conditions or security to adjust.
- A team leader should have their own dashboard, different to User or Manager.
- A team leader requires access to view manager approvals but not complete them.
- A team leader needs a different default landing page to users or managers when they log in.
- Team leaders are confused if they are looking at a User or Manager portal, they want different colors and names when they look at these portals. An example of where we should just give the Team Leaders the portal they need, not mash their experience by reusing ones tailored for other Personas.
Setting yourself up for success at the start will avoid any time consuming or risky refactoring in the future.
What about reuse?
An important question. Portals are a presentational layer, grouping of landing pages and cases for a curated end user experience. Reuse still applies here, and has never been easier in Constellation.
As a developer you can quickly configure a landing page, add it to multiple channels and even reorder it exactly as needed to curate the user experience desired for each Persona.
3. Access Groups and Personas
The presentational configuration is great, but what about security you ask?
We touched on this earlier, there are various rules created as the foundation for your access groups. Before you jump into Dev Studio to configure this, its important to understand how this configuration works in Constellation.
Configuration basics
Access Group and Managed Role
When a Persona is created, the corresponding Access Group is associated with a Access Role Name specific to that persona. This allows that Access Role Name to be configured in App Studio.
- It's important to note, that Role Based Access Control, inside App Studio, will only update the "managed role" specified in the "Enable access configuration in App Studio" checkbox.
Persona management wizard
This provides simple configurations via the App Studio wizard for Persona management. (Users > User Management > [Select Persona name]. This menu is currently not available in Dev Studio ('24.2 at time of writing).
Configuring these, directly changes the Access Role Name rule, for the "managed role", you can verify this in Dev Studio.
- Important note: The persona, by default has access to all Cases, Data and Configuration sets ('24.2 experience). This is represented in the Dev Studio rule as no configuration for that class (Access Role to Object rule). The moment you change the access in App Studio, an Access Role to Object rule will be created with the more refined access controls.
Sharing Insights via Explore Data and Dashboards (aka Reporting)
In addition to these features, Explore Data and Dashboards allow sharing with Access Group (Persona).
- This is an important circle back to our best practice - create new personas. In this example, if we only had User and Manager, then Team Leaders could not have specific role based Insights.
- Without this ability to curate the "Team Leader" experience, you're likely going to be chasing these requirements in even more complex fashions.
Avoid multiple access groups and portals - The "correspondence problem"
Still not convinced that giving each Persona their own unique Access Group and Portal is a good practice? Here's another all to common problem with complex "switch portal" implementations.
Inevitably, we are going to want to send emails to our users, notifying them of an important even in their application. This email is going to want to include a link to open the case related to this correspondence.
Once we start introducing multiple Access Groups and/or Portals for this application and this user, we start introducing complexity to this use case.
- How does the system know which Access Group to open this case with?
- How does the system know which Portal to open this case with?
In projects where time and resources are at a premium, simpler is always better.
Sure, it is possible to address these use cases with the construction of the hyperlink of the case OR even the login authentication and SSO rules, however, following best practices, we can avoid introducing this complexity all together.
Best practices Security vs Presentation
This is an important point drill down on. Configuring your portal or views to hide elements using visibility conditions does not secure that data. Unfortunately, we do tend to see this configuration approach overused - by creating the right access groups and configuring them with the right accesses, we ensure best practices to security are implemented.
Allowing a user to switch between different accesses, within the same application, can introduce unwanted and unecessary complications. Simpler is better.
See also Security.
Data Pages in Constellation and Switching
- Switching portals does not switch your security access (access group)
- Switching access group does change your security access but does not switch your Data Pages
Constellation is a stateless UI and optimised for a more performant run time experience. The end result is more caching of Data Pages than in Traditional UI.
By introducing switching of Portals or Access Groups, you can also introduce additional overhead to your development to invalidate Data Pages that have this kind of rule logic embedded in it. Creating distinct Persona/Access Group for each user base, can save you a lot more development in the lifecycle of an Application.
See also Data Pages and Data Pages in Constellation.
Configuring a "switch Portal" behavior
So we've got this far, and you still want to switch portal?
Remember, this can lead to poor User Experience and unnecessary complicated implementations.
- If you've skipped ahead to this section, I strongly recommend reading the earlier reasons why taking a simpler approach can save you long term maintenance issues and produce a better user experience.
After Switch Application? You can see more details in Switching between applications in a Constellation Portal
Option 1: Bookmark/Favorite your links to each portal
I love the fact Constellation Apps support multiple threads.
Gone are the days where
- our Single Page Application synched across multiple tabs (remember that?).
- I had to implement complex rules to allow users to open a link directly to a case
Whenever I'm on a client, I quickly bookmark all my applications so I can get to them without using the Dev Studio "switch access group".
In a real life example, this means I have a bookmark for:
- https://fgjadbse.pegace.net/prweb/PRAuth/app/my-pega-trial
- https://fgjadbse.pegace.net/prweb/PRAuth/app/examplebankingapplication
- https://fgjadbse.pegace.net/prweb/PRAuth/app/trainingforConstellation
Constellation application use the Application URL alias in the Application rule and pyRoutingTable rule to provide a superior level of control out of the box that we can all take advantage of.
Ok, great, what does that have to do with Portals? In this example, I'm assuming for each application, I only have one access group, mapped to one portal. My curated user experience loads exactly how I want using the Out of the Box configuration, loading my Operator Record (default app or specified app, and default portal in that access group).
Using this same approach, we can control this via the URL we bookmark/favourite. So in this example, the portal name is embedded in the URL to open the specific portal:
- User Portal: https://fgjadbse.pegace.net/prweb/PRAuth/app/my-pega-trial?portal=UserPortal
- Team Leader: https://fgjadbse.pegace.net/prweb/PRAuth/app/my-pega-trial?portal=TeamLeader
- Manager: https://fgjadbse.pegace.net/prweb/PRAuth/app/my-pega-trial?portal=ManagerPortal
Option 2: Pega landing page configuration
Constellation make configuring Landing Pages easier than ever before. This includes adding data to a landing page, sourced from any data page.
This provides an opportunity, if business needs require, to present a landing page of the different portals available inside your current application. Personally, i prefer option 1, but it is possible to configure a landing page like this.
For more details on configuring a landing page based on a datapage, see Configuring a list-based landing page
Option 3: DX Component
This option goes to the extreme of possibilities in Pega, we are now moving away from Out of the Box components to building our own. Although possible, careful consideration should be made if this is required for this particular use case.
I am yet to see a project implement a DX Component just for this use case, however, using the approach in Option 1 or 2, you can forsee a DX Component inspired by Pega Github component that could achieve this.
For more details on creating your own DX Components or being inspired by Pega's Github components, see:
- Develop Constellation DX components on Pega Academy
- Constellation DX components on Pega Docs
- Getting started on Pega Github
Share your experience
Share your implementation experience from your projects? Created your own DX component for this? Utilised the OOTB URLs? Let us know and lets share our learnings and good practices.
Useful articles