We’ve noticed that in Constellation, the Switch Application option now only works across entirely separate application instances. If multiple Access Groups point to the same application, users can no longer switch between them using this feature, only if the AG points to a completely different application.
We have business uses cases that involve granting additional access to users on demand—particularly during peak seasons when certain areas experience low coverage. For example, a user who typically works as a Document Analyst may need to temporarily take on the role of a Fraud Analyst to support the Fraud Queue. For the business, they should be able to switch between these roles/features throughout the day or week without losing their original Document Approver access to take work from both groups and access each role-related features. Previously, this was possible using the Switch Application feature, which was tied to the operator’s existing Access Group list.
We came across this article, which seems to discourage switching portals or Access Groups, suggesting that such functionality shouldn’t be necessary. However, we know that some clients still rely on this behavior due to how they are currently handling their business.
Is there still a way to support this kind of role-switching behavior in Constellation? Could it be achieved through the Switch Apps feature, a DX component from the Constellation UI Gallery, or any other approach? Or has this functionality been deprecated entirely, requiring a custom-built solution for clients who need it this way?
hi @DaliaP16 FDBK-135677 is created…product team will consider this feature available in the feature release.
Description
the out-of-the-box (OOTB) Constellation Work Portal does not permit logged-in users to switch their access group or persona within the same application. However, the ability for an individual to assume multiple roles is a common business practice, and an increasing number of clients are requesting this functionality. In traditional UI, this flexibility was achieved through the Switch Application feature, which was linked to the operator’s existing Access Group list…Therefore, this capability should be supported OOTB.
@DaliaP16 switch access group was a developer feature, no end user asks for the ability to click 3 times to launch a new portal that has different landing pages nor do they ask to get lost about which “access group has access to what”. These were always common issues with the traditional approach, a sub-optimal UX. As a former business user of Pega and having done countless user testing sessions, you see users get lost with this so often.
It has been discussed many times at a product level but with the ease of authoring a portal and its landing pages to give a persona access to what they need, there has never been a good UX argument for the old ‘switch portal’ to come back. Except that developers liked it.
If you have a business outcome where switching access group is needed, would love to know more about it. As @Chunzhi_Hong says, there is feedback on our backlog and this comes up from the development community often. I’m happy to put the case forward for it.
Options
Portals. As i mention in this article portals have a semantic URL you could use, to allow different views (its not different access groups though)
Yes, a custom DX component could achieve this. It is not without its headaches though, Constellation Architecture is different to Traditional. Caching for Data Pages is very different, so when switching you may have noticed in Dev Studio caching issues. That said, I know of at least one client who has overcome this to implement a custom solution.
Applications. As you said, this works between applications, so if you built an application on top of your current one, with its own access group, you could use the semantic URL for that application and effectively have access to a different access group to the same application OR use switch apps. I personally prefer the former.