Adding / removing role to a group with high number of users does not add / remove role to all the users in the group - Known Error

Adding / removing role to a group with high number of users does not add / remove role to all the users in the group Description Adding or removing a roles to/from a group with high number of users does not add or remove the role to/from all the users in the group. After the default time of 298 seconds, the transaction is cancelled by the UI Transactions quota rule. This issue can leave the group in an inconsistent state where not all the users have same role in the group.

Steps to Reproduce

Create a group. For more information, see the product documentation topic Create a user group . Add 5000 users to the group. Try to add a role to the group. For more information, see the product documentation topic Assign a role to a group . If the transaction completes before 298 seconds, add a few hundred users to the group. Try adding another role to the group. Repeat adding users and adding roles until the UI transaction quota cancels the transaction. Workaround On Madrid or later:

Add system property glide.ui.schedule_slushbucket_save_for_group_roles and set to true . This will cause group role additions or removals to be performed in the background, so it will not be immediately visible on the group and will need a refresh to confirm completion. If this works, when using "Edit" on the related list of a user group, you will see an information message at the top: On a version earlier than Madrid, choose from one of the following workarounds:

Increase the quota for UI transactions whenever such a long-running operation is performed by going to https:// .service-now.com/sysrule_quota.do?sys_id=88fe39123701200024d1973ebebe5dfd . Increase the value to a large number before running this transaction. The default value is 298 seconds. Write a simple GlideRecord-based script to perform the same action to add the role to the group in Scripts - Background. The background scripts are not subject to the UI transaction quota checks. Note that, although the fix for this is with the system property on Madrid, it is not enabled by default on instances.