See "Operator is available to receive work" option on Work Tab of Operator-ID instance. Check if this information helps.
Operator is available to receive work
Select to allow applications to route additional assignments to the worklist of the user who is identified by this Operator ID data instance.
Clear to prevent routing shapes in flow executions from adding assignments to this user's worklist.
This check box affects only routing activities. This check box does not affect the ability of this user to log in, enter work items, or complete assignments already on the worklist. It does not prevent another operator or manager from transferring assignments to the worklist.
If selected and at runtime a routing activity (with parameter CheckAvailability set to true) attempts to send an assignment to the worklist of this Operator ID, the substitute operator if any is used instead. If no substitute is found, the routing activity adds the assignment to the worklist of the manager of this operator's work group.
If you want to take it a step further and prevent the user from logging in, you can do the above to make the operator unable to receive work and then have an administrator change their password. When you want to give them access, you can give them the password/reset the password so they can log back in.
I don't think there is any OOTB functionality yet for this to directly revoke access to a user.
But updating Operator Availability and picking up Substitute Assignee (either another Operator or WorkBasket) can work if your requirement is to automatically re-direct work to other Operators/WorkBaskets. To access this, go to Operator Full Profile, then click on 'Availability' option (Similar settings can be configured in the Operator ID rule form -> Work tab - in Pega7). Also note that when you want to use this functionality, you might need to consider manually transferring all pending work that's already there in the user work list till the Operator was available. Further cases will get redirected once the 'Unavailable From' date is kicked off.
If the above option doesn't work for you and you are just interested to revoke access of the user, this can be achieved by updating user password (serves your purpose as it revokes user access). Assuming that internal authentication is being used, best way is build some functionality that will be available in admin portal (a section where admin user can choose the operator and changes password for any user). If you don't want to build anything new, a dedicated admin Operator in Production can use to change password by opening Operator ID records in Designer Studio.
In case if you are using external authentication, still you can request the user access to be revoked the same way as most of the Directory Service softwares can easily handle revoking user access and grant access at later point of time, when required.
I am not aware of any OOTB way to restrict the user login. I could think of 2 approaches - 1. you may want to keep a 'deny' list and check this list in authentication activity. 2. you could do the same 'deny' list check during portal load as well, I think.
In any enterprise system we don't touch the user id's in Pega. Since the authentication will be performed will help of any identity management system like LDAP, the id will be deactivated there.
may I know what's the use case, if you don't want any new work to be assigned to user than there are multiple ways to do that. if you don't want them to login, I feel create a table with all deactivated id's and at login check if id belong there, if yes, take them to error page and if not let them login.
Posted: 5 years ago
Updated: 5 years ago
Posted: 13 Nov 2015 16:12 EST Updated: 13 Nov 2015 16:13 EST
Create a Property isActiveUser in OperatorID class. Update the value to false for inactive users through a portal or may be with in authservice activity. In authservice activtiy, based on isActiveUser Challenge acustom screen to show the message or any link or button where user can reactivate their operator id if required.
In our current project, we went with the approach what Pavan has responded.
We created a property which tracks whether a User is active or not. Even though our authentication is controlled through LDAP, the client wanted this to be implemented. We get a file drop everyday of decommissioned users, we read that file using file listener and mark the operators as inactive.