Why workflow configuration is one of the highest-leverage decisions in your implementation
When organisations go live with Avature, the excitement is usually around the big-ticket items: the careers portal, the candidate experience, the reporting dashboards. Workflow configuration rarely gets the same attention, and that's exactly where things start to go wrong.
Poorly designed workflows don't announce themselves dramatically. They show up quietly: a recruiter waiting a few extra seconds every time they move a candidate, a report that doesn't quite reflect reality, a step that gets skipped because nobody really understood what it was for. Individually, these feel like minor inconveniences. Cumulatively, they erode trust in the platform and slow hiring down in ways that are genuinely hard to diagnose.
The good news is that most of these issues are entirely avoidable, and for organisations already live on Avature, most of them are also fixable.
What "poor workflow design" actually looks like
Before getting into how to design workflows well, it's worth naming what bad configuration looks like in practice, because it rarely looks like an obvious mistake at the time.
Steps without purpose or ownership. Every workflow step should have a clear reason to exist and a clear owner. When steps are added reactively (to solve an edge case, to satisfy a last-minute request during implementation) you end up with workflows where nobody is sure what certain steps mean or who is supposed to act on them. This creates inconsistent usage, which in turn creates unreliable data.
No naming conventions. If different implementation consultants, admins, or teams have configured parts of a workflow at different times, the naming of steps and actions will almost certainly be inconsistent. This makes workflows hard to read, harder to maintain, and nearly impossible to hand over cleanly to a new admin.
Steps that anyone can reach. Not every step in a workflow is meant for every user. Recruitment processes often include internal-only stages (steps used for compliance, scoring, or handover between teams) that candidates or external stakeholders should never see or interact with. Without role restrictions on steps, users can land in places they shouldn't, causing process errors and occasionally compliance issues.
Actions that fire when they shouldn't. Step actions in Avature are powerful, but they need conditions to control when they execute. Without proper action conditions, you end up with emails sending at the wrong time, fields updating incorrectly, or automation triggering on records it was never meant to touch.
The performance problem nobody warns you about
One of the most underestimated risks in Avature workflow design is performance degradation. And it's almost always a configuration problem, not a platform problem.
Avature workflows have recommended limits that exist for good reason: no more than 750 actions per workflow, and no more than 25 actions per step. These aren't arbitrary numbers. When a workflow exceeds these thresholds, the consequences are real: workflows that take a long time to open or save, step updates that hang while recruiters wait, and in serious cases, configuration changes that don't save at all.
The frustrating thing is that when this happens, it usually gets misdiagnosed. Recruiters report that "the system is slow." IT raises it as a platform issue. In reality, it's a configuration overload, and the fix is in the workflow design, not in a support ticket.
There are a few patterns that reliably cause this:
-
Too many actions in a single step. When a candidate reaches a step, Avature executes all actions configured to run "as soon as the step is reached" sequentially. If there are 20 or 30 actions at that step, the system makes the user wait while every single one completes before they can do anything else. The fix is to split actions across steps: keep only what needs to happen immediately at the entry step, and use a delayed update step to move the record to a second step where the rest of the actions fire in the background.
-
Workflows that have grown organically over time. A workflow that started with 200 actions and has had things added to it for months or even years can easily exceed the 750-action limit without anyone noticing. Regular audits (reviewing which actions are still needed, merging redundant actions with smarter conditions) are a routine part of keeping an Avature instance healthy.
-
Bulk operations hitting action-heavy steps. Import services and mass actions process records in bulk. If those records are landing on a step with many synchronous actions, the combination can cause serious slowdowns. The same intermediate step approach applies here: configure the target step to handle only what must happen immediately, and let the rest follow via a delayed step.
Designing workflows that hold up over time
Good workflow design isn't just about avoiding problems, it's about building something that can be maintained, extended, and handed over without starting from scratch. These are the principles that experienced Avature implementation consultants apply from day one.
-
Separate your subprocesses. A common mistake is trying to model an entire recruitment process in a single workflow. Complex processes have variants: different hiring tracks, different regions, different business units. Trying to handle all of that in one workflow leads to bloat and confusion. A better approach is to build a root workflow that handles what's common across the whole process, and branch out into separate workflows for each significant variation. This keeps each workflow readable and maintainable.
-
Use preconditions to enforce process integrity. Avature allows you to set preconditions on workflow steps. These are conditions that must be met before a record can enter that step. This is one of the most misapplied features in implementations, yet one of the most valuable. For example, you can configure a step to check that all mandatory fields are completed before a candidate can progress. If the form isn't filled, Avature will surface it as a dialog for the user moving steps to complete. This turns what would otherwise be a data quality problem into a guided process experience.
-
Name everything intentionally. Steps and actions should all follow a consistent naming convention from the start. This is not just an aesthetic preference, it has a direct impact on how long it takes to onboard new admins, diagnose issues, and extend the configuration later. Teams that inherit a well-named workflow can understand it in an hour. Teams that inherit a poorly named one can spend days trying to figure out what it does.
-
Use action conditions rather than duplicating actions. A recurring source of workflow bloat is creating separate actions for every scenario, when a single action with well-designed conditions can handle multiple cases. Before adding a new action, ask whether an existing one can be extended with a condition instead.
-
Be deliberate with delayed actions. Delayed actions in Avature go into a queue, and the timing is dependent on server load: five minutes configured in Avature is not necessarily five real minutes. This matters for processes where timing is important. Use scheduled actions for delays longer than roughly a week, and avoid using delays as a workaround to force a specific step order. Avature has a dedicated feature for defining step order, use it!
-
Handle destructive actions carefully. Purge and delete actions are difficult or impossible to roll back. ‘Purge’ removes data from a person record (which is typically what GDPR-related processes require); ‘delete’ affects reporting integrity. For either action, always configure a delay (even five minutes) so that a recruiter who moves a record to the wrong step has a window to catch and correct the mistake.
What this means after go-live
Most of the above applies at the point of implementation. But the reality is that many Avature customers are already live, and many of them are living with workflows that were configured under time pressure or at a time where not all the current workflow features existed.
The encouraging thing is that workflow configuration is one of the areas where targeted optimisation work delivers fast, visible results. An instance health check that identifies the ten most action-heavy steps, cleans up unused actions, and restructures two or three bloated workflows can meaningfully improve the day-to-day experience for recruiters, and all of that without touching anything that disrupts the live process.
For TA leaders, this is worth understanding because the symptoms of poor workflow design (slow system, inconsistent data, low recruiter adoption) are often attributed to the platform itself. In most cases, the platform is fine and it’s configuration that needs attention.
Getting that right, whether at implementation or as an optimisation project, is the difference between a system your team works around and one they actually rely on.
