I have multiple action flows seggregated by country and other attributes. All the AFs are writing to the same table in the data pool. Due to the execution runtime limit, I had to create multiple action flows instead of one action flow.
Now all the AFs are scheduled to be executed every Monday. I can not schedule all AFs half an hour apart, as the count of AFs will only grow in the future and writing back to the data model for all AFs may take more than a day to complete. And to use trigger at each AF is troublesome to maintain.
Is there any easy way, where I can trigger the first AF execution on Monday and all other AFs will be executed one by one without any deadlock.
Question
Scheduling action flows' execution one after another
+1Hi Arunjit,
Yes, there's a straightforward way to do this. Since Celonis Action Flows run on the Make engine, the cleanest approach is to chain the flows event-driven — keep the schedule on only the first flow, and have each flow start the next one when it finishes. Nothing runs in parallel, so there's no deadlock on the shared pool table, and you can keep adding flows without touching any schedule.
Recommended setup — webhook hand-off
Give every Action Flow except the first a Custom webhook trigger instead of a Monday schedule:
- The first AF keeps the Monday schedule. As its last module, add an HTTP → Make a request step that calls the second AF's webhook URL.
- Each subsequent AF is triggered by its webhook and ends with an HTTP call to the next AF's webhook.
- The last AF in the chain triggers the data model reload.
Because each flow only calls the next after its own final module completes, execution is strictly sequential — each scenario only runs for its own duration (so no single flow hits the runtime limit), and there's no lock contention on the table.
To keep maintenance low as the number of flows grows
Instead of hard-coding "who runs next" inside each flow, keep an ordered list in one central place — a Make Data Store or a small ordering/config table in the data pool. Each flow's final step looks up what comes after it and triggers that flow (via webhook, or via Make's Run a scenario API using the scenario ID). Onboarding a new flow then becomes a single row added to the list, with no edits to existing flows.
One important optimization on the reload
If each flow currently triggers its own data model reload, that's likely the real reason the end-to-end run takes so long — and reloads can collide too. Separate the two concerns: each flow should only write to the pool table (append/upsert, no reload), and trigger a single data model reload at the very end from the last flow. That turns N reloads into one and removes the biggest source of contention.
Net recommendation: schedule only the first flow on Monday, have each flow trigger the next via webhook driven by a central ordering list, and reload the data model once at the end.
Login to the community
No account yet? Create an account
Login with SSO
Celonaut Login Celonis ID LoginEnter your E-mail address. We'll send you an e-mail with instructions to reset your password.