ALERT! The community will be read-only starting on April 19, 8am Pacific as the migration begins. Read more for important details.
ALERT! The community will be read-only starting on April 19, 8am Pacific as the migration begins.Read more for important details.

SBM User Management Process App

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.

User Management WorkflowUser Management Workflow

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.

Application Administrator Scheduled TaskApplication Administrator Scheduled TaskFor 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.



Some content on Community Tips & Information pages is not officially supported by Micro Focus. Please refer to our Terms of Use for more detail.

Thanks David I will test this. I can tell that this will be a great feature. 


When you set the user status to 2, Disabled, how does the sytem behave with respect to the user when login attempts are made.  In the workflow I have developed to manage users and groups, I automate this process in a similar manager except I change the password, append "(Inactive)" to display name and loginId which effectively prevents users from loging in.  

So when I read about the field STATUS setting to 2 can Disable account, I expected the behavior above without all the effort.  Upon setting the field to 2, the status field displayed Disabled.  So I logged in as the user in question, nothing prevented me from logging in and system automatically set the STATUs field to 0 which I believe is Active.

Am i missing something?


How did you set the status to 2?  If you set it by SQL query, you will get the behavior that you describe.  SBM caches the users table, so updating the database directly will not work.  However, if you update the user record via the AppRecord object, the cache is automatically refreshed.  It also logs the edit to the Admin History record.  Here is how I did it in ModScript.

def disableUser {

  var userRec = Ext.CreateAppRecord( Ext.TableId("TS_USERS"));
  userRec.ReadWithWhere( "TS_ID = ?", [Pair(DBTypeConstants.INTEGER,userID)]);
  var locked = userRec.Lock();
  var unlock = userRec.Unlock();


I would not suggest to leave users in the disabled state indefinitely.  I would think that you would want to remove them from their ownership roles so that they can be deleted if necessary.  My process app demonstrates the use of Approved By and New State Owner as ways of maintaining history data for reporting purposes.  Without these fields, you still have the change history; it just does not allow for quick auditing.

That's verbatim how I have mine set.  I tried a direct modification of the db  and also via the AppRecord object but same result.  My work flow syncs all system users and moves them to states Active, Disabled or Deleted depending on the system value for status.  Also when I have account requests submitted  into the work flow process it goes through the approval process and usually lands in the disabled state.  Once account is ready and approved, i move it to the Active State which then updates system tables including the status field to Active.

Maybe there is an issue with your version.  I suggest gathering info and submitting a case.  



Top Contributors
Version history
Revision #:
8 of 8
Last update:
‎2020-08-13 23:14
Updated by:
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.