Mistake 01Building before the process was understood
The canvas gets opened on day one. Nobody documented the current process, agreed the exception paths, or asked which steps exist only because a retired system once required them. The automation is then a faithful reproduction of the old mess, running faster.
It happens because opening the designer feels like progress and interviewing people feels like delay. The cost arrives later: every subsequent change fights a structure that encoded assumptions nobody wrote down, and the approval nobody has ever rejected is now enforced by a machine that never gets tired of enforcing it.
Do this insteadMap the process as it is actually performed — including the workarounds — before building. Separate the steps that create value from the steps that exist out of habit, and delete the second group rather than automating them. Deleting a step is always cheaper and faster than the automation would have been.
Mistake 02No error handling, so failures stop silently
An action fails — a connected system timed out, a record did not match, a credential expired — and the instance simply stops. There is no alert because nobody configured one. The first signal is a customer asking where their contract is, days later.
Nintex provides an error-handling panel precisely so a failure can be captured and handled rather than ending the instance. The subtler version of this mistake is worse: the error is captured, and then discarded. The workflow appears to have completed, the failure is invisible, and the bad state is now in your data.
Do this insteadGive every action that touches an external system a defined failure behaviour: retry with a bound, escalate, compensate, or stop and notify. Every captured error must reach a named person — a handled error nobody is told about is worse than an unhandled one, because it looks like success.
Mistake 03Loops that log or call out on every iteration
A loop was written against a test collection of five records and now runs over five thousand. Inside it sits a logging action, or a call to an external service, or both. The history becomes unusable, the workflow slows to a crawl, and the external system starts rejecting calls because they are arriving faster than it allows.
Nintex's own guidance is explicit here: keep iteration counts to the minimum, avoid writing to the workflow history inside a loop, and introduce a pause within long-running loops to relieve pressure and reduce the chance of throttling. This is the single most common performance finding we make.
Do this insteadCheck what the collection actually contains at production volume. Move external calls out of the loop where possible and batch them where the API supports it. Log decisions and outcomes, not iterations. Where a long loop is unavoidable, pause inside it as the platform guidance recommends.
Mistake 04A trigger that re-fires on the workflow's own writes
The workflow starts on a record change. Partway through, it updates that same record. The update is a change, so the workflow starts again. In testing with three records nobody noticed; in production the instance count climbs until something gives.
This one is genuinely easy to miss, because the workflow is correct in isolation. The defect only exists in the relationship between the trigger condition and the write-back, and it will not appear in a functional test that walks the happy path once.
Do this insteadWrite a trigger condition that excludes the workflow's own service identity, or that fires only on the specific field changes a human would make. Then add an alert on instance volume, so if a recursion is ever introduced it is caught in test by a number rather than in production by a bill.
Mistake 05Copying a workflow instead of parameterising it
Region two needs the same process with a different approval threshold, so the workflow is copied and the threshold edited. Then region three. Then a product variant. Two years later there are seven near-identical workflows that have quietly diverged, and a defect fixed in one survives in the other six.
Copying is always faster on the day and always more expensive afterwards. It is the single largest contributor to estate sprawl we see, and it is almost never a deliberate decision — it is what happens when there is no rule about it.
Do this insteadMake parameterisation the default and copying the exception that has to be argued for. One workflow reading its thresholds, approvers and routing from configuration handles many variants, and a fix applies everywhere at once. Where a genuine fork is justified, record why — so the next person does not assume it was an accident.
Mistake 06Tasks assigned to a person rather than a role
The approval goes to a named individual. They go on leave, change role, or leave the organisation — and every instance waiting on them stops. Nobody notices for a fortnight because there is no due date, no reminder and no escalation path.
A related version: the routing rule can assign a task to the person who raised the request, which either creates a silent self-approval or an instance that waits forever on someone who is not expecting it. Both are people problems expressed as workflow defects, and both are designed out rather than trained out.
Do this insteadAssign to roles or groups rather than individuals, with a due date, a reminder, a delegation path and an escalation that fires on a timeout. Add a rule that a task can never be assigned to its own requester. For long-running processes, resolve the assignee when the task is created, not when the instance started.
Mistake 07Default names, no descriptions, and no action sets
A canvas of thirty actions carrying their default labels, variables called Variable1 and Text2, and no description on the workflow itself. It works. Nobody can read it. The person who built it left last year.
Nintex supports action sets for grouping related logic, editable action labels that say what the action does, and a variable naming convention that makes the data type visible at a glance. None of this is advanced, and all of it is skipped under deadline pressure — after which the estate quietly freezes, because changing something you cannot read is frightening.
Do this insteadName the workflow's purpose in its description, label every action with what it does rather than what kind of action it is, group related logic into action sets, and name variables so their type is obvious. Then apply the review test: could an analyst who has never seen this find the approval threshold and change it safely?
Mistake 08Building directly in production
There is one environment. Changes are made live, tested live, and occasionally broken live. It is genuinely faster — for about one sprint. After that it is the reason nobody will touch a business-critical workflow during working hours, and the reason a change has to be planned like an outage.
The compounding problem is that connections and environment-specific values end up hard-coded, because there was never a promotion step to force them to be parameterised. Introducing environments later is then a migration rather than a configuration change.
Do this insteadSeparate development, test and production with their own connections and credentials, and establish a documented promotion path. Parameterise environment-specific values from the start so a promotion does not require re-pointing every action by hand. This is far cheaper on day one than in year two.
Mistake 09Parallel branches used by reflex
Several things could happen at once, so they are all put in parallel branches. Under test it is faster. Under production volume the concurrency multiplies calls into rate-limited systems, ordering assumptions that were never true start to matter, and behaviour becomes hard to reproduce.
Nintex's guidance cautions against heavy use of parallel branches and suggests a serial process where the parallelism is not genuinely buying anything. The cases that cause trouble are usually the ones where two branches share a resource, or where one quietly depends on something the other does.
Do this insteadUse parallelism where the branches are genuinely independent and the elapsed-time saving is real. Serialise the rest. Check explicitly for hidden dependencies between branches assumed to be independent, and test at volume rather than with three records — this is a defect class that only appears under load.
Mistake 10No owner and no measurement after go-live
The project ends, the team disperses, and the workflow runs. Nobody owns it. Nobody is watching cycle time, exception volume or whether people are using it at all. It degrades gradually and invisibly, and the first real signal is a complaint or an audit finding.
This is the mistake that causes the other nine to recur. An estate without owners accumulates copies, loses its documentation, and stops being reviewed — so every pattern above reappears in the next build, and in the one after that.
Do this insteadName a business owner and a technical owner before go-live, not after. Instrument the process so cycle time, stall points and exception rate are visible on a cadence somebody reads. Review the estate quarterly and retire what has stopped running. None of this is expensive; all of it is skipped.
