We have a need to switch a users access group, default workgroup and skill via Okta login depending on how they log in. There is obviously Pre-authentication and Post-authentication activity points.
Is this possible and if so how do we do it using OOTB as much as possible?
They are existing users with one set of AG, WG and Skill but, we need to be able to switch their existing AG, WG and Skill to another set depending on how they login. It shouldn’t be permanent as in they have existing sets now and during login we change them to suit the app.
Hi Kamil,
Could you please elaborate how we can change the AG while authenticating. We are using SAML SSO and in post authentication activity we are setting the AG (based on some conditions) on the Operator record pyAccessGroup property and saving it but it is still launching the old default AG portal. If we see the operator record it is showing the updated AG as the default one. But only when we log off and log in it is picking the AG we set.
Thanks,
Bhasker
We’ve done something similar using that private method, but we were hoping for something OOTB and need as I mentioned, ability to change not just access group but skill and default workgroup.
This doesn’t appear to work. I’ve copied your java code and implemented in our customised activity ApplicationProfileSetup and added this
if (!origAG.equals(NewAccessGroup)) {
try {
auth.setActiveAccessGroup(tools.getThread(), NewAccessGroup);
oLog.infoForced(“Got here and switched access group to “+ NewAccessGroup);
}
catch (Exception e) {sSwitchResult=” Can not login : Can not switch access group” + e.getMessage();
oLog.error(sSwitchResult);}
}
It logs the infoForced message but the pxThread.pxCurrentAccessGroup does not change.
Any ideas?
UPDATE
Never mind my fault, this only works when user has the other access group in their list of access groups.
Thank you for the support. Upon further investigation, we identified the activity Data-Portal.pzSwitchPortalAndAccessGroup, which internally leverages the same underlying Java implementation and accepts the access group as a parameter.
This approach eliminates the need to maintain custom Java code, thereby reducing future dependencies on code updates and improving overall maintainability, as it relies on a standard internal function.