- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
11-28-2024 01:42 PM
I am trying to make a scheduled job that runs once a day. The purpose of this scheduled job is to look into all active incidents which contain at least one person in the watchlist and remove any inactive users from the watchlist. Can anyone help with this?
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
11-28-2024 05:02 PM
Ok, I built this out for the practice. Before we start, please be aware that Glide_List fields are simply strings that store comma separated sys_ids. Observe.
You'll also need to define two flow variables
- NewWatchList: this will store our valid user sys_id's to pump back into the watch list
- RemovedNames: This will store a string of friendly user names that we removed from the watch list. This isn't required, just going to make your Incident work notes more informative.
Here's the flow....
My first look up was just to a single sample Incident. You'd want to look up a set of records then do a For Each to loop through them. Anyway... here's what my sample incident started with. Akila P is inactive
My first For Each is simple. Just a For Each entry in the incident's Watch List.
Since the For Each is getting a user reference each time, lets ask if that user is active.
If the user IS active, lets pump their sys_id to flow variable NewWatchList, which is a string that will contain comma separated sys_ids. Don't copy this verbatim as the code will change based on the node you're pulling from and yours might not match mine. If you've never scripted values in flow you type in fd_data. and the system helps you fill in the rest. Its how you access your Data Picker via script. Super noice.
This code says "combine the NewWatchList variable with whatever its previous value was, plus a comma, plus the sys_id of the user I'm currently on in the For Each.
So if the user is NOT active, lets add their name to flow variable RemovedNames. Notice this time I'm not getting the user's sys_id, I'm getting their name!
Now that we've looped through all the users in the watch list, lets update the Incident. But we only need to update IF there were users to remove. We'll know if the cleanse was unnecessary if RemovedNames is not empty.
Now we just update the watch list (with NewWatchList) and then add a charming little work note to inform people which users have been removed from the watch list.
BOOM!! Cleansed watch list and informative work note if users were removed. (forgive me I was too lazy to hyper optimize the grammar of the work note update.)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
11-28-2024 05:02 PM
Ok, I built this out for the practice. Before we start, please be aware that Glide_List fields are simply strings that store comma separated sys_ids. Observe.
You'll also need to define two flow variables
- NewWatchList: this will store our valid user sys_id's to pump back into the watch list
- RemovedNames: This will store a string of friendly user names that we removed from the watch list. This isn't required, just going to make your Incident work notes more informative.
Here's the flow....
My first look up was just to a single sample Incident. You'd want to look up a set of records then do a For Each to loop through them. Anyway... here's what my sample incident started with. Akila P is inactive
My first For Each is simple. Just a For Each entry in the incident's Watch List.
Since the For Each is getting a user reference each time, lets ask if that user is active.
If the user IS active, lets pump their sys_id to flow variable NewWatchList, which is a string that will contain comma separated sys_ids. Don't copy this verbatim as the code will change based on the node you're pulling from and yours might not match mine. If you've never scripted values in flow you type in fd_data. and the system helps you fill in the rest. Its how you access your Data Picker via script. Super noice.
This code says "combine the NewWatchList variable with whatever its previous value was, plus a comma, plus the sys_id of the user I'm currently on in the For Each.
So if the user is NOT active, lets add their name to flow variable RemovedNames. Notice this time I'm not getting the user's sys_id, I'm getting their name!
Now that we've looped through all the users in the watch list, lets update the Incident. But we only need to update IF there were users to remove. We'll know if the cleanse was unnecessary if RemovedNames is not empty.
Now we just update the watch list (with NewWatchList) and then add a charming little work note to inform people which users have been removed from the watch list.
BOOM!! Cleansed watch list and informative work note if users were removed. (forgive me I was too lazy to hyper optimize the grammar of the work note update.)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
12-03-2024 09:43 AM
This worked, thank you very much
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
11-28-2024 05:49 PM
Hi @ValeriaS and @Uncle Rob
We did something very easy, we just added a condition to the Dictionary Entry for the watch list:
Just add a condition like the one below and any task where the Watch List is populate by a user that becomes inactive, they will be automatically removed.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
11-29-2024 05:02 AM
Started digging into this @Luiz Lucena because I suspected the reference qualifier would block selection, but leave existing inactive user entries in-tact. Here's what I found.
Reference qualifier definitely blocks entry. Here's my user, akila p. As you can see... inactive.
Here's a brand new incident, attempting to add akila to the watch list.
But here's an older incident with akila already on the watch list. She still remains (and is visible) on the interface.
So just letting you know, legacy entries of inactive users are still there if you're using reference qualifier only. I'll bet that's not a problem 99% of the time, but data is data, and if you were running any scripts or logic... that won't care if the user is active or not.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
11-29-2024 10:00 AM
hello @Luiz Lucena, I did this already but as @Uncle Rob if there was an incident which had the user already and then that user becomes inactive, it does not remove the user. I have been trying to achieve this with an scheduled job. This is what I have so far:
Not sure what I might be doing incorrectly, can any of you advise?