How to bulk delete user's via background script after cloning

[attanhes]

I'm trying to bulk delete 'Inactive' users from the sys_user table using a background script after a clone, but it's taking a long time to delete even 10 users records. After a while, the system becomes unresponsive.

var gr = new GlideRecord('sys_user');
gr.addQuery('active', false);
gr.query();

var count = 0;
while (gr.next() && count < 10) {
    gr.deleteRecord();
    count++;
}
gs.print('Deleted ' + count + ' inactive users.');

Is there any better way to doing the above script ?

I tried multiple record deletion as well, but same result.

var gr = new GlideRecord(sys_user);
gr.addQuery('active', false);
gr.setLimit(10); //limit only first  2 record 
gr.query();
gr.deleteMultiple();

I noticed there's a 'Clone Cleanup Script', but I've never used it before and I'm not sure how to test it either.

[J Siva · Accepted solution]

Hi @attanhes 
May I ask why you want to delete the records? It's generally not a best practice to remove foundation records. However, if you prefer not to see inactive users in sys_user table, you can set up an archive rule to move them to the archived table. I assume this is being done in non-production environments.

Regards,
Siva

[attanhes]

Thanks, everyone. My goal is to clone configuration only to the sandbox environment for a project. I was able to successfully separate the data and clone configuration-only for all modules, except for the sys_user table.

When I excluded the sys_user table and its associated tables as advice by Service Now, certain functionalities broken even though XML import into sandbox.

So now I'm working on Plan B — cloning all users and then deleting the unwanted users in the sandbox environment which is not ideal.

[J Siva]

@attanhes ok got it..

Try to run the same in fix script (run background).

[attanhes]

Thanks, J — your tip was very helpful. I archived the unwanted users in the non-prod environments and then cloned the target while excluding the archived(ar_sys_user)table. Problem solved!

No needed to run background script after cloning to delete the accounts as unwanted user accounts already left in source in that way.  I would never recommend doing this in a production environment as mentioned in J's post. Fortunately, I was working with two non-prod instances for this exercise.