How to stop triggering SC task from Business rule?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
12-11-2024 04:26 AM
Hi
I have requirement like to stop triggering the SC task 2 when the first SC task 1 state set to closed skipped How can I get this one from Business rule.
Note: This requirement is for 500 catalog forms so I cannot modify it on individual workflow I want to achieve it from Business rule
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
12-11-2024 02:39 PM
The script is easy enough to write... but you should be warned in certain terms.
This will permanently and invisibly prevent mature processes from being built in your environment.
You're disabling your service managers from properly defining services, and preventing your successors from understanding why sc_tasks don't work the way their flows tell them to.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
12-11-2024 06:26 PM
I agree with Rob.
Please discuss this requirement with your business, the script is simple
Ankur
✨ Certified Technical Architect || ✨ 9x ServiceNow MVP || ✨ ServiceNow Community Leader
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
12-11-2024 05:23 AM - edited 12-11-2024 05:25 AM
As you're already discovering, using business rules to manipulate how sc_tasks operate is DANGEROUS.
First, because you'll ALWAYS find yourself in this kind of position: trying to edit its operations at the caprice of new requirements.
Second, because when you move on to better opportunities, NOBODY will know how this works, and they'll be left wondering why Flow isn't working *like its supposed to*.
Third, you CAN'T arbitrarily make this principle universally applicable.
"For a new hire, do tasks A, B, and C. sc_task A was closed skipped, therefore all other tasks are skipped". NO! It could *very well be* that the process demands B & C still proceed. You're projecting a developer preference onto something that belongs in the hands of the process owner. Stakeholders HATE that when dealing with ServiceNow teams internally.
Yeah, it sucks that the GOOD WORK of establishing how flows are supposed to work wasn't done on the first 500 catalog items. Anything you do now to avoid the better practice is just accruing a ton of interest on your tech debt.