Workflows rarely fail outright at scale. They just get slow, and slow enrollments quietly pile up until reports look wrong, follow-ups arrive late, or the queue never actually clears. The three usual suspects are re-triggering loops, sequential steps waiting on outside systems, and enrollment triggers that are wider than they need to be.
In This Article
Why "it works" and "it works at scale" are different questions
Most workflows get tested against a handful of contacts before launch, and they pass. That test tells you the logic is correct. It doesn't tell you what happens when 8,000 contacts hit the same enrollment trigger in one afternoon, or when a delay step that felt negligible at 50 contacts becomes a multi-hour backlog at real volume.
The symptoms at scale rarely look like a failure. They look like a workflow that's "still running," a follow-up email that goes out a day later than it should, or a report that shows fewer completed actions than contacts actually enrolled. Nothing throws an error. It just gets slower than anyone planned for.
The three most common performance killers
- Re-triggering loops. A workflow updates a property, and that property change re-enrolls the same workflow, or a sibling one watching the same field. Each pass looks fine individually. Stacked up, they multiply the total work the portal has to process for a single contact.
- Sequential steps waiting on outside systems. A webhook or custom code action that calls out to an external API adds real wait time, and if several of those sit back-to-back in the same branch instead of running in parallel, that wait time adds up fast across a large enrollment batch.
- Enrollment triggers wider than they need to be. A trigger that enrolls "everyone, then filters deep inside the workflow" processes far more records than one that filters at the door. The extra enrollments still consume workflow capacity even when they get filtered out two steps in.
If enrollment counts spike and the time to clear the queue grows faster than the enrollment count did, that's not a coincidence. That's usually one of the three killers above compounding under load.
A practical audit checklist
- Check the enrollment trigger first. Could it be narrower, filtering at the door instead of two steps in?
- Look for any property this workflow updates that could re-enroll it, or another workflow, into a loop.
- Find every custom code action or webhook step. Do any of them sit sequentially when they could run independently?
- Pull the actual enrollment history for the last real-volume run, not the test batch, and look at where time is actually being spent.
- Confirm delay steps reflect real business need, not just a default that was never revisited.
When to split a workflow instead of optimizing it
Sometimes the honest fix isn't a faster version of the same workflow. It's two workflows instead of one: a lean enrollment-and-filter workflow that decides who actually qualifies, feeding a smaller, focused action workflow that does the real work. Splitting responsibilities this way usually outperforms trying to optimize a single workflow that's grown to do everything.
Test any fix against a realistic volume, not a handful of records. A change that looks like an improvement on 50 contacts can behave completely differently once a few thousand hit it at once.