- Post History
- Subscribe to RSS Feed
- Mark as New
- Mark as Read
- Bookmark
- Subscribe
- Printer Friendly Page
- Report Inappropriate Content
on ‎03-16-2021 03:37 AM
The Application
We uploaded our new application Automatic Group Member Management to the ServiceNow Share.
The app can be used to handle group memberships automatically based on certain conditions. The conditions can be either based on a user (e.g. Department = IT) or based on user references of a record (e.g. department head in department table). You also have the choice to write a script for the users who should be part of the group.
The app automatically adds new users which fulfill the conditions and delets users which do not fulfill the conditions anymore.
With the included member history you can audit the group memberships and build reports on the data.
Use Cases
Not sure why you could need the app? We currently use the app for the following standard use cases:
- Put all Department Heads in one group
- Put all Knowledge Base Owners and Manager in one group
- Put all Cost Center Manager in one group
- Put all Users from a certain location in one group
Key Features
In Version 1.1 the following key features exist:
- Automatic user assignment to a group based oon
-
- user conditions
- user references on a record (e.g. department head in department table)
- scripted list of users
- user list
- group list
- Addionaly restrict users based on user conditions (e.g. only active users)
- Track added/deleted users for auditing
- Script-API to start the evaluation process, e.g. from a Business Rule or Import Job
Initial Configuration
- Download the latest version from Share and install the update set in your instance.
-
Allow Delete Access for Group Member Table
- Navigate to System >> Tables
- Open the table Group Member (sys_user_grmember)
- Open the tab Application Access and set Can delete to true.
- Save the record
- Your Application Access should now look like the following
Create a Group Config
The Key Entry Point for the configuration is the module Group Configs. A group config defines the User Group and wether the member history should be tracked or not. You can run the Process directly from the record with the UI Action Run. If you want to test your configuration you can run Run Preview. The preview does not insert/delete any user from the group.
Create a Rule
To define which users should be part of the group you have to create rules for it. Every user who matches one rule will be added to the group.
The rules can be based on a record set with a user field or directly on the sys_user table.
The tab User Configuration can be used to to apply additional conditions on the users found by the record configuration (e.g. all Department Heads which are active).
[Optional] Configure the scheduled job
You can find the example scheduled job Process Active Group Configs in the Scheduled Script Executions. The scheduled job processes each active group config synchronously. You can copy the scheduled jobs and configure it as you wish.
[Optional] Use the Script API in your processes
The API x_msgfi_agmm.GroupProcessorAPI provides two functions
- execute (groupConfig)
- executeAsync (groupConfig)
The parameter groupConfig can be one of the following:
- GlideRecord of the group config
- SysID of the group config
- Number of the group config
var api = x_msgfi_agmm.GroupProcessorAPI()
var runRecord = api.executeAsync('AGMM00001');
// runRecord is the GlideRecord of the Run Table (which stores information about the run)
- 4,824 Views
- Mark as Read
- Mark as New
- Bookmark
- Permalink
- Report Inappropriate Content
Hey Sebastian,
I'm looking to utilize this product at my company, and currently testing out its features. It's mentioned a few times that you can determine group membership based on a User (the example you give is "Department = IT"). However, when I go to create a rule, I have to fill out fields within the "Record Configuration" section to some extent to provide the initial list of users that will then be filtered further by the conditions in the "User Configuration" section.
Is there not a way to just straight up look at the sys_user table itself, and provide the conditions for the sys_user records that you want to have added to a group without determining the list of users to filter on initially? I'm not pulling the list of users from a related record's reference or list fields, I just want the filter I apply on sys_user. For example, we have a custom field on sys_user that is a reference to Job Title records we have created. I'd like to be able to create a rule for a group config record that adds all users where "Active = true" && "Job Title = <insert title record here>".
In a pinch, I could just use the "Script" Record Type, and make my own GlideRecord query on sys_user to provide the users, however it then makes the "User Configuration" section seem redundant. If this functionality doesn't exist, then perhaps that would be a recommendation for an update, is that if you select a Record Type of "User", you can either select specific sys_user records, (though why wouldn't you just add that user to the group manually instead of create an automation for it?) or you are given the option to just provide the condition for which sys_user records should be added to the group similarly to the current filter used in the User Configuration section.
Thanks
- Mark as Read
- Mark as New
- Bookmark
- Permalink
- Report Inappropriate Content
Hi
you can do this directly on the Record Configuration by using Record Table = sys_user.
The User Configuration is then not needed.
- Mark as Read
- Mark as New
- Bookmark
- Permalink
- Report Inappropriate Content
Perfect, thank you for the image showing how to set it up. The piece I was missing was setting the "Record User Fields" with sys_id. I had noticed it as an option, but didn't think to use it, as I was under the impression it was going to try and search that field for a user, similar to other reference fields, but I when I stop think about it, reference fields just contain the values of sys_ids themselves, so I can see how it would work.
Thank you again for the clarification as well as the screenshot showing the example setup. Much appreciated!
- Mark as Read
- Mark as New
- Bookmark
- Permalink
- Report Inappropriate Content
Unfortunately I cannot update my own article anymore.
Migration from V1.1 to V2.0+
In V2.0 we reparented the group config table from "Metadata File" to "Scheduled Script Execution". Due to the reparenting both versions are not compatible.
!!! Important!!!
During the migration the app will be reinstalled and there all data will be lost. Be cautious and test this on a sub-prod instance before.
Migration Steps:
- Export all group configs as XML
- Export all rules as XML
- Export or save all customizations you did
- Delete the application
- Preview and commit the new V2.0 update set (you can ignore all update set errors for "Found local update which is newer than this one"
- Import group config XML
- Import rule XML
- Run fix script "Update AGMM script fielafter reparenting"
- Update the number counter on group config as this will be reset
- Add all your customizations if you have some
- Mark as Read
- Mark as New
- Bookmark
- Permalink
- Report Inappropriate Content
Love the tool! We are using for various use cases to maintain group membership. A new use case is wanting to use this to keep our resource groups updated with latest resources. Looking for some insight on script needed to look at the current group manager and then query all users active and manager is same as the group manager.