SBM User Management Process App
Solutions Business Manager (SBM) is a robust and powerful business workflow system. It can orchestrate and talk to third party systems with ease and little code. Time to development can be minutes or hours compared to days or months of other systems.
It helps to take a little time to consider user roles when starting a new process app. A little focus here can help clean up time (and possible frustation levels) needed when employees leave the company or position and access needs to be removed. Most issues revolve around item ownership, and are easily resolved with a little planning.
Review KB S142912 for more details and use cases to consider when working with user fields. These use cases allow for separation of duties where an access administrator is responsible for restricting / adding access to various systems. Such an administrator may not have detailed knowledge of each system. In such case, SBM can be used to develop a workflow to aid in cleaning up the loose ends. When deactivating an user in SBM, for instance, it is necessary to deal with ownership issues. These things can be handled via the process app after the initial disabling of the user.
Example Process App
Attached is a sample process app. It shows how to disable the user via web services and ModScript. It also provides an example of handling user fields in a robust way. See the snapshot and blue print for this process app. Start by importing and promoting the snapshot. This will setup a project with project level overrides for roles. You will need to edit the roles for the User Management Project to assign one or more groups to the Approvers and Implementors roles. You will want to assign all users to the Users role. This is used to populated the SBM User drop down list.
We use the workflow for user management. As we look at the workflow, let's notice how it handles ownership and users. First, the new state assigns its owner in a field called NewStateOwner. If a user needs to be deleted from SBM, any current items in the new state owned by this user will need to be reassigned because of an item cannot be owned by a deleted user. However, we will maintain in the submitter field that this deleted user is the one that submitted it. Given the change history available in SBM this is not strictly necessary since it documents the initial value of submitter. However, it is at times nice to preserve the initial value of submitter for reporting.
* Edit the worflow > Submit transition in App Admin and set the default value for NewStateOwner to '(Current User)'. The promotion should have done this already.
Now, we do a Make Ready transition to the Ready state. Here I did not assign an owner, but assigned the approvers role to secondary owner. Now, by deleting the user, I do not affect ownership requirements, and I do not need to alter role assignments at this time. If the user simply requires a different role in the company, I can disable the user from the role and assign the user to a new role with little effort. The approvers field gives us one or users that can approve the item.
What next? We actually approve it. During the approve transition, we set the Approved By field to be the current user transitioning the item. Approved By never owns the item, but it provides easy listing report to know which users approved each item. Again, the change history records this information if you choose not use the Approved By field.
* Edit the workflow > Approve transition in App Admin and set the default value for Approved By to '(Current User)'. The promotion should have done this already.
Once in the Approved state, the Implemented By field holds the Implementors that can complete the test as secondary owner. Here I use the same field to preserve the actual person that actually did the task. The Complete Task transition sets the Implemented By field to be set to the default value of '(Current User)'.
* Edit the workflow > Complete Task transition in App Admin and set the default value for Implemented By to '(Current User)'. The promotion should have done this already.
Using secondary owner only and not primary owner may be valid for your team dynamic. However, sometimes it is best to assign someone specific to handle a primary resource. If that person gets reassigned or leaves the company then you will go through this workflow to disable the user and remove the user field defaults, selections and notifications using user "references" in Application Administrator.
The "Complete Task" transition in this workflow disables the user via transition modScript and moves the item to completed. The workflow can be expanded to include steps such as preparing to delete user or even to re-enable the user upon request.
This process app contains a branch to schedule a user to be disabled. This can be done via delayed notification as it enters the Disable on Inactivity state. It does contain the notification modScript required to actually disable the user. Once disabled, the administrator can do what is necessary to complete the process and delete the user as necessary.
For automated user management, look at the script "disable Inactive Users". This script should be scheduled in SBM to disable any user that has not logged into SBM in the last X days. Create a scheduled task in the SBM Application Administrator > Scheduler. Run it daily. Add the parameter "InactiveDays" and set it to the number of days of inactivity allowed. If this parameter is not available then the script will log an error and not run.