Architect: Hidden Concurrency Limits for Parallel Data Actions in Call Flows

I’m doing some deep research into Architect’s execution limits. I’ve found an interesting (and undocumented) behavior regarding ‘Parallel’ execution.

If you use a ‘Split’ block to run multiple paths simultaneously, and those paths each execute a ‘Call Data Action’, the platform seems to have a hard concurrency limit of 5. The moment I try to run a 6th Data Action in parallel, it fails with a 504 Gateway Timeout-not because the endpoint is slow, but because the Architect engine hasn’t even sent the request yet. It seems there’s a thread pool limit of 5 for Data Actions per conversation. Has anyone else hit this wall? I’m trying to optimize a high-complexity triage flow and this is forcing me to serialize everything, which is killing my ‘Average Speed to Answer’.

I’m managing our PureConnect migration and we’ve noticed that Architect is much more ‘opinionated’ about resource management than the old PureConnect handlers were.

This ‘Limit of 5’ is likely to protect the Edge server’s memory. Each parallel Data Action requires a dedicated thread and a socket. If you have 1000 calls all trying to run 10 parallel actions, you’d crash the media service. The 504 is a ‘Fail-Fast’ mechanism.

To optimize, you should combine your Data Actions into a single ‘Composite’ API call if possible. Instead of calling GetBalance, GetStatus, and GetAccountType separately, build a single endpoint on your side that returns all three in one JSON object. It’s much cleaner and bypasses the concurrency limit entirely.

I’m on the change management side, but I’ve sat in on the architecture reviews for our rollout. One thing our lead architect mentioned is that ‘Parallel’ in Architect isn’t ‘True’ parallel-it’s more like ‘Interleaved’ execution.

If you’re hitting timeouts at exactly 5 actions, you might want to try adding a ‘Wait’ block (0.5 seconds) in one of the parallel paths. Sometimes giving the engine a few milliseconds to breathe between starting the requests can prevent the ‘Pool Exhaustion’ error. But honestly, 's suggestion to consolidate your APIs is the real ‘Masterclass’ solution here!