Question
Stratosphere Technical Consulting
US
Last activity: 24 Jun 2019 10:08 EDT
When switching applications, need to switch more than just access group
In version 7.3.1, we have a requirement for operators to be able to switch between multiple applications that are all hosted in the same instance. These applications have dependencies other than just on the access group itself, which appears to be the only thing that changes with the OOTB swith applications control.
Say the operator IDs need to be structured like this:
|
Access Group |
Work group |
Skills |
Workbaskets |
|
App1ClaimsIntake |
ClaimsIntake |
English Spanish |
ClaimsIntakeWest |
|
App2PolicyUpdate |
PolicyAdmin |
|
PolicyAdministration |
|
App3ClaimsApprover |
Approver |
English French Italian |
ApproverWest |
When an operator ID is saved with the first row of data, and that operator uses the OOTB switch applications control to change to App3ClaimsApprover, the work group, skills, and workbaskets remain unchanged in the operator ID record and on the clipboard.
In version 7.3.1, we have a requirement for operators to be able to switch between multiple applications that are all hosted in the same instance. These applications have dependencies other than just on the access group itself, which appears to be the only thing that changes with the OOTB swith applications control.
Say the operator IDs need to be structured like this:
|
Access Group |
Work group |
Skills |
Workbaskets |
|
App1ClaimsIntake |
ClaimsIntake |
English Spanish |
ClaimsIntakeWest |
|
App2PolicyUpdate |
PolicyAdmin |
|
PolicyAdministration |
|
App3ClaimsApprover |
Approver |
English French Italian |
ApproverWest |
When an operator ID is saved with the first row of data, and that operator uses the OOTB switch applications control to change to App3ClaimsApprover, the work group, skills, and workbaskets remain unchanged in the operator ID record and on the clipboard.
Since various parts of the App3’s configuration are built requiring the App3ClaimsApprover to be in a certain work group and have access to certain workbaskets, the operator is not able to see various reports and work.
What is the best way to deal with this need?
Pegasystems Inc.
US
Have not seen this use case although others appear to have. My experience is with changing access group dynamically on login. Perhaps, that can be a jumping off point for a solution of a different nature.
For now though, since you are looking at OOB "switching applications" functionality, I have found a suggestion from past discussion where the use case was changing the workbasket in tandem with application switch.
Suggest first have to associate your workbasket to the application. Maybe use pyLabel of workbasket for that to indicate which WB belong to which application. Once you do that, you can customize RD pyWorkbasketsinMyworkgroup , ie change filter condition to something like .pylabel contains Application.pyLabel.
Changing the WorkGroup might be more challenging. I'd be interested in hearing how far this WB suggestion would take you.
Stratosphere Technical Consulting
US
I didn't have any luck with this requirement, and the use case has changed for me such that I've gone to roles-based access and removed dependencies on workgroups and workbaskets for routing and team member displays.