thank you for the response. For whatever reason, I can't see the image clearly.
But yes, different org structure and potentially workgroups per application. Now, granted the different org structure may or may not be a complete one from Organization level but probably more like a different leaf of the org structure (not sure if this correct view of it -- perhaps lack of knowlege on my part). But at the same time, a different active workgroup may be required as well; context could be a HR-admin app vs HR finanance app vs Internal corporate app vs Business purpose-driven app. And the [potential] "requirement" of switching between them... Perhaps there is a better way of doing this besides switching apps/portals?
I wanted to follow up with trying to provide more details on the scenario.
Org structure and workgroup definition are assigned to the operator. (as opposed to the application)
If we have two applications running on the same Pega installation, what's the best way to deal with switching apps but also ensuring the workgroup and org structure defined for the operator remain appropriate for the requirements of the application. The only solution I can think of is customizing the switch app (operator menu) to perform the adequate logic to setup the correct operator details.
App 1 has org structure ORG-DIV1-Unit2 and workgroup-A
App 2 has org structure ORG-DEV2-Unit3 and workgroup-B
So when switching from App 1 to App2 (or vice-versa) , the operator details are updated to reflect the appopriate App requirements for org structure and workgroup.
Is there a better way of doing this?
We are currently using Pega 7.1.8 which limits the operator to only one (1) workgroup so switching is required
I know Pega 7.2.1 has ability for multiple workgroups (question with that is how is the default/active workgroup defined)
Hmm. @Avinash. Not quite; The default you are showing is the Access Group. I am looking at default workgroup. So, going with your example. The Accounts:Administartors has a default workgroup of accountsWorkgroup.
The DMSample:Administrators has a default workgroup of sampleWorkgroup.
When the user logs into the system, the default application would be the portal associated with the Accounts:Administrators access group (with default workgroup of accountsWorkgroup). If user switches portals to DMSample:Administrators, I would like the default workgroup for the user to switch to sampleWorkgroup.
As we authenticate via Active Directory, the process of switching applications would need to re-authenticate (to ensure they are authorized for the application being switched to) and the default workgroup would need to be changed as well. The only way that I can think of doing this is customizing the Switch Portal construct. The other problem with this is switch to one app and back again, you have completely lost the context you were in with the initial application. Is there any other way of doing this? (I am just afraid I am missing a more elegant design/implementation)
thank you for the reply. By switch application script you are speaking of the one via Designer Studio, correct? If we are authenticating users via SSO (against Active Directory) then we would need to update the script to trigger
re-authenticate against AD
Re-Authorize for proper access group definition/matching against appropriate access group
re-define the default workgroup
re-define (if necessary) the default org structure.
Is this thinking correct and/or is there a better way of handling this when a user (non-developer) wants to switch portals and/or application?
I would think the original authentication could give the end user access to multiple end user access groups and then you could mirror the switchapplication seen on the OOTB navigation menu pyCaseManager (option Switch Apps) (seen on my 7.1.8 box) which can switch between any of the apps populated onto the availableapps pages on the pxSecuritySanpshot page. pxThread.pxSecuritySnapshot.pxAvailableApps