Is there some way that within a workflow, we could modify its own triggers?
Context: data comes in bursts into my database. When it comes, I may need to process quickly multiple entries, thus running the workflow multiple times (loop is a pain that I am choosing not to investigate yet) so I want to trigger it every minute.
However, when things are calm, checking every minute is a waste of resources.
Is there some way to have a thing where
1 if there is data to process (I know how to check), run the workflow every minute until there is no more pending and go to option 2
2 if there is no data to process, run the workflow every hour to check for data and go to option 1
The reason is to limit the number of runs of the workflow when it's not needed, to save on the quota of bandwidth/runs available to our plan - and save some trees while we're at it, by reducing our energy footprint
Basically is there some workflow block that I can use to alter the trigger of the workflow?
I have something similar where webhooks call my workflow and most of the time it sends a single item, but sometimes it's an array of data. To handle it, I first check if it's an array (or an array.length > 1) and if it is, I do use a loop to call the workflow endpoint repeatedly for each item in the array, 1 at a time.
In the webhook itself, that initial check on array.length is always === 1 for the looped calls, so that branch processes everything as normal.
If your data is just going into a DB, I don't think there is any way to have the DB trigger your workflow based on a row being added, but maybe your DB provider has a feature like that.
Now, if you don't care about how quickly your workflow runs after the data is run, then you could take the same approach mentioned above, run it every hour with a flow like:
trigger -> hourly
check db for rows
-> yes -> grab the first row -> process -> clear row -> call workflow again
-> no -> do nothing (don't call the workflow again)
```
Then your workflow would be triggered by the hourly CRON job, and just keep calling itself until it runs out of rows to process.