What is your goal?
I am testing with synthetic data in an isolated scenario. Several source messages for one logical key are collected during a short debounce window. After the window, one classification result must produce one consolidated informational reply from all regular content and one independent invocation of an existing action subflow for each action request. A single source message may contribute to both projections.
What is the problem & what have you tried?
I need a Make-native composition that keeps the regular reply independent from action failures and reuses an existing action handler only after the batching boundary, without re-entering the top-level webhook, classifier, or debounce path.
Each action must receive its original payload and a stable operation ID.
Would you recommend structured output followed by Router + Iterator, scenario inputs/outputs, or a callable subscenario?
In particular:
- How would you aggregate the regular projections once while iterating each action independently?
- How can an existing internal action branch be exposed safely as a callable subflow without sending the action through the top-level webhook again?
- How should error handling be scoped so a failed action cannot cancel, duplicate, or block the consolidated regular reply?
No blueprint, endpoint address, identifying data, or credentials are included.
Hey there,
if I understand you correctly, you are looking for a router with filters after it. So each actionable item will be sent on a dedicated path. Then on the last route you have an aggregator that consolidates whatever is needed for the single message.
There are two ways to handle failures. You either add error handling directly in the main scenario (depending on what’s needed, anmodule to send a slack message that something broke followed by ignore will not break the entire flow), or have each path trigger a separate scenario so failures can be isolated there.
Then for the secondary scenarios → using the subscenarios with the scenario inputs is a good way, but the main scenario will still wait for the subscenario to finish before proceeding. Using an HTTP module where you send a JSON to a webhook to trigger a secondary scenario allows for a queue and the main scenario to work independently of the subscenarios.
Router plus Ignore on the action routes keeps the consolidated reply alive, agreed. Subscenarios will still block the parent, so HTTP to a second webhook is the isolation that actually survives an action failure.
What is still missing is the debounce store: write the logical key plus a stable operation ID when the window opens, and refuse a second consolidated reply if that ID already went out. Where are you holding the window — Data store, or a sheet?
If the number is currently active through WATI’s WhatsApp Coexistence setup, I’d definitely avoid disconnecting WATI until the migration path is confirmed.
The “Not eligible” status could indicate that Meta still considers WATI the active provider for that number. The important question is whether Make can take over the existing Coexistence registration directly, or whether WATI must first release the number through Meta’s system.
I’d recommend confirming this with Make Support before making any changes, specifically asking whether disconnecting WATI will preserve the existing WhatsApp Business App registration and whether there is any re-registration or cooldown period. That way, you can avoid putting the existing number at risk during the migration.
The debounce window lives in per-conversation state in our own service, with one serialized state owner per conversation. It is not stored in a Make Data Store or a sheet.
Stable operation and delivery IDs are enforced in that state layer. We do not treat a Make Data Store check-then-write or a blind retry after an ambiguous HTTP outcome as an exactly-once guarantee.
The Make scenario therefore receives the batch only after the debounce boundary, produces one consolidated regular projection, and invokes each action independently through a dedicated entry point that cannot re-enter the debounce flow.
Thank you both, your replies confirmed the direction and clarified why the action invocation should remain isolated.