- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
08-02-2024 08:13 AM - edited 08-02-2024 08:14 AM
I have a bit of an interesting problem. I need to run a script at the end of our hiring process. Unfortunately for me the people that initially set up those processes where years before me. I am still trying to track down all the processes, but it appears that there may be 4-6 different workflows for the new hire process (depending on how the new hire is started).
That said, I am trying to run a script at the end of that process off of one of the SCTASKs created from the process (usually there are 3; Account creation, Facilities details, Hardware deployment). I am also trying to track down if they are at least consistent with the description for the Hardware deployment in each of these workflows. As I try and pull all that info together, I am trying to think of the best way to target a script to that SCTASK. Before I found out that there were multiple starting points (each with a different flow) I was just going to work it into the flow, but now I am not so sure.
The other (probably poor on efficiency) way I was thinking was a business rule that runs when an SCTASK is closed to check if it meets the criteria of the target SCTASK then run the script that way, but that leaves it separate from the actual process and leaves room for it to fail if changes are made to the hire process (I would add this to the documentation stream if I could find it...)
Any ideas on this would be greatly appreciated. Thanks.
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
08-02-2024 08:33 AM
I'd run the script with the business rule as you said, and add in the work notes of the task/RITM that triggers it "Automated message: Script to do x finished successfully". This makes it more visible for future developers.
Maybe a better trigger would be the RITM closure, and add in the BR condition the catalog items for which it should run. Then you are not dependent on the 'description for the Hardware deployment in each of these workflows'.

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
08-02-2024 08:19 AM
Are you able to update the workflow to run a script once that task is created/closed? That would probably be the best approach.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
08-02-2024 08:48 AM
I am, but then I am creating it in at least 4 different workflows. Personally, I would have created a subflow for the generation of the Catalog Tasks, that way, any of the different workflows would share would should be an identical process. I am going to suggest this to the platform owner, but that will take too long to clean up and implement, and I am already being pressed to get this process out the door.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
08-02-2024 08:33 AM
I'd run the script with the business rule as you said, and add in the work notes of the task/RITM that triggers it "Automated message: Script to do x finished successfully". This makes it more visible for future developers.
Maybe a better trigger would be the RITM closure, and add in the BR condition the catalog items for which it should run. Then you are not dependent on the 'description for the Hardware deployment in each of these workflows'.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
08-02-2024 08:52 AM
Good point on the RITM, though the RITM itself may vary from each different new hire process. I was thinking that in each workflow I could clean up (at the least) the hardware creation ticket, so that they all follow the same design. To be honest, they all do the exact same thing, and it pains me that they created multiple workflows for almost the same identical process. Yes, there are some things that differ at the start, but when it comes down to the final SCTASKs they are all the same, just drafted differently because they were probably made by several different devs. I personally have not worked a lot with workflows (I have done a few flows recently and am familiar with those), so I don't want to break anything trying to fix a different problem.