Asset scheduled workflow automators don't trigger child asset types, as Event-based automators do
I’ve noticed an issue with the new (otherwise AMAZING) scheduled automators - they don’t trigger child asset-types as they should.
For example, if you’d like to run an event-based workflow for all Laptops + Desktops + Servers, you would just use the Computer parent asset type. This works for event-based workflows. However if you use schedule-based workflows, the workflow must use the Laptop asset type specifically.
For my testing, I used 1 Laptop asset and 6 automators:
Therefore to make a schedule-based workflow system for the Computer asset type, I would need to make 3 rather than 1. That would be even worse for more generic higher-level asset types.
Has anyone else had a similar experience?
Cody P
Page 1 / 1
It's important to be aware of the differences between asset scheduled workflow automators and event-based automators in terms of triggering child asset types. While event-based automators can trigger child asset types, asset scheduled workflow automators do not have this capability. This means that if you need to trigger a workflow for a child asset type, you may need to use an event-based automator instead.
However, asset scheduled workflow automators still have their own benefits and can be useful in certain situations. For example, they allow you to automate the processing of assets on a regular schedule, which can save time and improve efficiency. Additionally, they can be used to trigger workflows for specific asset types, even if they don't trigger workflows for child asset types.
Overall, it's important to consider the specific needs of your workflow when deciding which type of automator to use. If you need to trigger workflows for child asset types, an event-based automator may be the best choice. However, if you need to automate the processing of assets on a regular schedule, an asset scheduled workflow automator may be more appropriate.
Hi @cody.pieper ,
Adding to @Aiedwards155 This is currently a behavior since the Scheduled Workflows would have to check on each and every asset on a timely basis, We run high-end jobs in the backend for it to be run on a particular time for these assets, The more the assets, The higher jobs it would require and hence the more time and space complexity. This is why we thought it’d be best to leave out the child assets to cut down the cost of complexity and have a smooth trigger. Let me know your thoughts!
It's important to be aware of the differences between asset scheduled workflow automators and event-based automators in terms of triggering child asset types. While event-based automators can trigger child asset types, asset scheduled workflow automators do not have this capability. This means that if you need to trigger a workflow for a child asset type, you may need to use an event-based automator instead.
However, asset scheduled workflow automators still have their own benefits and can be useful in certain situations. For example, they allow you to automate the processing of assets on a regular schedule, which can save time and improve efficiency. Additionally, they can be used to trigger workflows for specific asset types, even if they don't trigger workflows for child asset types.
Overall, it's important to consider the specific needs of your workflow when deciding which type of automator to use. If you need to trigger workflows for child asset types, an event-based automator may be the best choice. However, if you need to automate the processing of assets on a regular schedule, an asset scheduled workflow automator may be more appropriate.
Thank you!
Definitely agree! I was a little unsure if this was an intended design - it sounds like it from Amy’s response below :)
Hi @cody.pieper ,
Adding to @Aiedwards155 This is currently a behavior since the Scheduled Workflows would have to check on each and every asset on a timely basis, We run high-end jobs in the backend for it to be run on a particular time for these assets, The more the assets, The higher jobs it would require and hence the more time and space complexity. This is why we thought it’d be best to leave out the child assets to cut down the cost of complexity and have a smooth trigger. Let me know your thoughts!
Thanks Amy!
That makes a lot of sense - I had considered it might be intended, but wasn’t sure. From the perspective of the amount of potentially daily requesters per asset, that would indeed make it quite a large pool of requests occurring all at once.
My only thought around that, is I do wish that duplicating automations allowed for the asset type to be switched prior to duplicating. But I also understand why it can’t :)
Thanks for your inputs!
Kind regards, Cody
This thread is a little old. I have this workflow down to the lowest child asset type but it still won’t run. In fact, I can’t get any of my scheduled asset workflows to run. Any ideas what I am doing wrong?
This thread is a little old. I have this workflow down to the lowest child asset type but it still won’t run. In fact, I can’t get any of my scheduled asset workflows to run. Any ideas what I am doing wrong?
I have a ticket open currently at FreshService e#14598225] because the scheduled workflows for our server assets do NOT trigger at all unless you create a NEW manual server asset which was not imported by the discovery probe. Then it will trigger on only that asset. Support was not able to recreate the situation but it looks like you might experience this as well now.
You can check by manually creating a Laptop test asset and see if it runs on that asset
so this was the answer here:
Thanks for letting me know that this now works as expected.
The developers had noticed a timeout from the backend and the orchestration timeout flag was not enabled and hence due to huge volume of requests, the workflow wasn't proceeding for other assets.
We have enabled the timeout flag and that had resolved the issue.
Since the flag has been enabled now, this issue should not come up in the future.
