It got slower and nobody knows when
Instances that used to complete in minutes now take hours. Usually the workflow did not change — the data volume did, and a loop that was fine over fifty records is not fine over five thousand.
Nintex Workflow Optimization
Most Nintex estates do not need more workflows. They need fewer, working properly.
Estates accumulate. A workflow gets copied for a new region, a form is duplicated for a new product, someone leaves and their builds stop being touched. Eventually it is slower, more expensive, and nobody dares change the parts that matter most. Twopir Consulting audits what is actually running, retires what is not earning its place, and re-engineers what is. Inventory, triage, performance remediation, consolidation, governance.
Estate Triage Twopir · 2πr
Layer 01
The Estate Today
Workflows Forms Templates Connections
Layer 02 · 2πr
Triage
Retire Repair Re-architect Keep
Layer 03
The Estate After
Runs Faster Costs Less Changeable
First Finding The retire pile is nearly always the biggest one
What does Nintex workflow optimization involve?
Nintex workflow optimization is the assessment and remediation of an automation estate that already exists: inventorying what is deployed, establishing what actually runs and who owns it, fixing the workflows that fail or degrade under load, consolidating duplicates, retiring what is dormant, and putting governance in place so the estate does not re-accumulate. It is the engagement you want when the problem is not "we need automation" but "the automation we have is slowing us down".
It is the counterpart to Nintex workflow automation, which covers building to a standard in the first place, and it frequently runs alongside implementation when an estate is being migrated — because the cheapest migration is the one that carries the least across. Both sit inside the wider Nintex consulting practice.
It fails intermittently and gets re-run by hand
There is a person whose job partly consists of restarting things. That is a missing retry, not a personality trait, and it is usually a few hours of work to remove permanently.
Nobody knows what half of it does
Workflows with default action names, no descriptions and no owner, built by people who have left. Changing anything nearby feels dangerous, so the estate gradually freezes.
The same workflow exists six times
One per region, product or business unit — copied rather than parameterised. They have since diverged, so a defect fixed in one quietly survives in the other five.
The licence cost no longer matches the value
You are paying to carry workflows nobody has run in a year, and support effort is going into things that should have been retired. Nobody has ever been asked to justify the estate as a whole.
Permissions and connections are a security question
Workflows running under a departed employee's identity, connections with broader access than they need, and no record of which workflow reaches which system. This tends to surface first during an audit.
Eight things we look at before recommending anything
The audit is deliberately evidence-first. We would rather tell you three quarters of the estate is fine than find work that is not there.
Inventory and real usage
Everything deployed, with how often each item has actually run. Execution history separates the estate you think you have from the one you are paying for.
Ownership
Who owns each workflow in the business and who owns it technically. "Nobody" is the most common answer and the single strongest predictor of everything else on this list.
Performance profile
Duration by workflow and by stage, and how that has moved as volume grew. This is where loop and throttling problems show up long before anyone reports them.
Failure and exception rate
What fails, how often, and what happens next — including the failures nobody is alerted to because the error is captured and then quietly discarded.
Duplication
Near-identical workflows, forms and templates that should be one parameterised item, plus how far they have drifted apart since they were copied.
Identity, permissions and connections
What each workflow runs as, what each connection can reach, and whether any of it depends on a person who has left. Usually the most urgent findings sit here.
Documentation and readability
Naming, descriptions, action labels and action sets — because an estate nobody can read is an estate nobody will change, whatever its technical condition.
Cost and licence fit
What the estate costs to licence and support against what it demonstrably delivers, so the renewal conversation is based on evidence rather than on last year's number.
Four piles, and how we decide which is which
Every item in the inventory lands in exactly one of these, with the reasoning recorded so the decision can be challenged by whoever owns the process.
| Classification | Criteria | What we do | Relative effort |
|---|---|---|---|
| Retire | No recent executions, no owner, duplicated by something else, or serving a process that no longer exists. | Confirm it is genuinely dormant with the business, record the decision, then decommission it cleanly rather than leaving it disabled and forgotten. | Lowest. Usually the largest pile and the fastest saving. |
| Repair | Serves a real process and mostly works, but fails intermittently, degrades under volume, or requires manual intervention. | Targeted fixes — retry and error handling, loop restructuring, throttling relief, alerting to a named owner. | Low to moderate, and the best return per hour in most estates. |
| Re-architect | Business critical, structurally fragile, and cannot be changed safely — often the one everyone is most afraid of. | Redesign against current standards, rebuild in a non-production environment, and cut over with the old version kept available until confidence is established. | Highest. Scoped individually and never started without a named owner. |
| Keep | Runs reliably, has an owner, is understood, and nobody needs to change it. | Nothing. It goes in the register with its owner recorded and we move on. | None. We will not bill to rewrite working things to a house style. |
The audit report gives you the four piles with the evidence attached. It is useful whether or not you engage us for the remediation — several clients have taken the retire list and actioned it themselves, which is a perfectly good outcome.
Symptom, cause, and what we actually change
These account for the large majority of performance findings in estates we inherit. None of the fixes is exotic; most are a day or two of work each.
| Symptom | Usual cause | What we change |
|---|---|---|
| Slow at month-end, fine otherwise | Calls to an external system made inside a loop, hitting that system's rate limits once volume rises. | Move the call out of the loop, batch where the API supports it, and introduce a pause between iterations as the platform's own guidance recommends. |
| History unusable, instances crawling | A logging action placed inside a loop, writing an entry per iteration and flooding the workflow history. | Remove logging from inside loops, log decisions and outcomes instead of iterations, and keep the history readable enough to use during an incident. |
| Unpredictable behaviour under load | Heavy use of parallel branches, which multiplies concurrent work and makes ordering assumptions unsafe. | Reduce parallelism to what genuinely benefits from it, serialise the rest, and remove any hidden dependency between branches that were assumed independent. |
| Runaway instance counts | A workflow updating the record it is triggered by, re-triggering itself in a loop nobody noticed until the numbers were large. | Add a trigger condition that excludes the workflow's own service identity or field changes, and an instance-volume alert so it cannot recur silently. |
| Regular manual restarts | No retry configured, so any transient error becomes a permanent stop that a person has to notice and repeat. | Bounded retry with a delay, separation of retryable from permanent errors, and a give-up path that alerts a named owner rather than stopping. |
| Forms slow to open | A form loading far more data than the user needs, often every possible lookup value at once. | Load on demand rather than upfront, scope lookups to the relevant subset, and split a form nobody can navigate into a short sequence. |
| Long-running instances behaving oddly | Configuration captured at start — approvers, thresholds, org structure — that has since changed while the instance was still running. | Read configuration at the point it is used rather than at start, assign to roles rather than individuals, and define what an in-flight instance does when the workflow is updated. |
Platform limits differ by edition and change between releases, so we verify yours against your tenant rather than quoting a number. The same failure patterns, written for reading rather than buying, are in 10 common Nintex workflow mistakes.
Stopping it from accumulating again
A one-off clean-up buys you about eighteen months. These five habits are what make it hold — and they are cheap compared with doing the audit again.
Nothing goes live without a named owner
A business owner and a technical owner, recorded at deployment. This single rule prevents most of what the audit found, because unowned items are where every other problem accumulates.
Copying a workflow requires a justification
The default answer to "we need a version for region two" is parameterisation. Copying is allowed, but it has to be argued for — which is usually enough to stop it happening by reflex.
A peer review before production
One other person reads the workflow and confirms it meets the conventions and has a failure path. Fifteen minutes, and it catches the overwhelming majority of what this page is about.
A quarterly look at the numbers
Execution volume, duration trend and failure rate reviewed on a cadence. Degradation is gradual and invisible day to day; a quarterly comparison makes it obvious while it is still cheap.
An annual retire pass
Anything that has not run in a defined period is challenged. The default is retirement and the burden is on keeping it — which is the opposite of how estates normally work, and why they normally grow.
Questions about fixing an existing estate
It scales with the size of the estate and, more than anything, with how quickly we can get read access and speak to the people who know what things are for. The inventory and execution analysis is largely mechanical. The slow part is ownership archaeology — working out who is accountable for a workflow whose builder left two years ago. We scope it after a short look at the estate size rather than quoting blind, and the deliverable is a report with the four piles and the evidence behind each classification.
Fixing, in almost every case we have assessed. A rebuild throws away the institutional logic buried in workflows that do still matter — the edge cases, the thresholds, the exceptions that were added for a reason nobody remembers but that will be missed immediately. It also takes longer than anyone estimates. The exception is a genuine platform migration, where you are rebuilding anyway and the only question is how much you carry across. There, the audit still comes first, because it decides what not to migrate.
This is the most common blocker, and the answer is a staged retirement rather than an argument. Execution history usually settles it — a workflow with no runs in twelve months is not in use, whatever anyone believes. Where doubt remains, we disable rather than delete, communicate it, and wait an agreed period covering the process's full cycle including any annual events. If nothing surfaces, it is decommissioned properly. If something does, it is re-enabled and reclassified, and you have learned something real.
Sometimes, and it depends entirely on how your agreement is structured — some licensing models respond to reduced usage and some do not, so we will not promise a saving before looking at yours. What optimization reliably reduces is support effort, the cost of manual intervention, and the risk carried by fragile business-critical workflows. Where the licence conversation is genuinely in play, the audit gives you evidence of actual usage to negotiate with, which is usually stronger than the position you had before.
The audit itself is read-only and disrupts nothing. Remediation is sequenced by risk: retirements first because they are lowest risk and free up attention, then repairs which are usually contained changes tested in a non-production environment, then re-architecture, which is handled as a small project per workflow with the previous version kept available until the new one has proven itself over real volume. We do not batch fifteen changes into one release on an estate that is already fragile.
Not for us, and we try to keep it professional in the report. Most of what we find is the ordinary consequence of an estate growing over years under changing requirements and staff, not evidence of bad work — and a build that was entirely reasonable for the volume it was designed for can still be wrong for today's. The report describes what the current state is and what we would change, without inviting you to blame anyone. That tends to make the remediation easier to get approved internally, too.
Next Step
Find out how much of your estate is still earning its place
The audit is read-only, disrupts nothing, and produces a report you can act on with or without us — including the retire list, which is usually the fastest saving available.
Fewer workflows, each one owned, documented and working
