The demo workflow always works. The production one meets a throttled API, an approver on leave, a loop that now runs four thousand times, and a record that does not match. Twopir Consulting designs Nintex workflows around those cases first — because at volume they are not edge cases, they are most Tuesdays. Routing, forms, human tasks, branching and exception handling, built to a standard.
Nintex workflow automation is the use of the Nintex designer to express a business process as a sequence of triggers, conditions, system actions and human tasks that runs without anyone coordinating it by hand. Nintex supplies the designer, the connectors and the runtime. What decides whether the result lasts is the design underneath: how the logic is structured, how state is handled, and what happens when a step does not succeed.
| Component | What the platform gives you | The design decision that actually matters |
|---|---|---|
| Start event | Triggers on a record change, a submitted form, a schedule, or an inbound API call. | Whether the trigger can fire on its own side effects. A workflow that updates the record it listens to will re-trigger itself unless the condition excludes it. |
| Variables | Typed variables for text, number, date, collection and object values. | Typing them correctly and naming them so the type is visible at a glance. Loosely typed collections are where most late-stage defects come from. |
| Conditions & branching | Conditional actions and parallel branches. | Whether every branch has a defined end, including the one nobody expected to be taken. Unhandled branches stall silently. |
| Loops | Iteration over collections, with the ability to pause inside a loop. | Iteration count at real volume, and whether logging or an API call inside the loop multiplies into a throttling problem. |
| Human tasks | Task assignment with due dates, reminders, delegation and reassignment. | What happens when the assignee has left, is on leave, or is also the requester. Approval chains break on people far more often than on logic. |
| Forms | Form designers with rules, validation and repeating or table sections. | Validating at the point of entry rather than three steps later, so bad data never enters the process at all. |
| Error handling | A configurable error-handling panel that captures an error instead of letting it fail the instance. | Distinguishing a retryable transient failure from a permanent one — and making sure a captured error still reaches a person. |
| Action sets | Grouping related actions into a labelled set. | Using them, consistently. This is the single largest factor in whether someone else can read the workflow a year later. |
The pattern is consistent: work that crosses systems, needs human judgement somewhere in the middle, and has to leave an auditable record at the end. That is the shape Nintex fits.
One request fans out into accounts, access, equipment, payroll and training, each with a different owner and a different system — and offboarding has to reverse it on a date that matters for security.
Routing by value, risk and clause deviation, with legal involved only when the thresholds say so — and the signed version filed against the source record rather than in someone's mailbox.
Requests validated against budget and vendor status, approved against the authority matrix, then posted to the finance system as a transaction rather than retyped from an approval email.
From closed-won to a live, billable customer: document generation, verification steps, account and entitlement setup, and the handoffs between sales, finance and delivery that normally leak days.
Periodic reviews, policy acknowledgements, access recertification and exception approvals — where the evidence trail is the deliverable and a missed deadline is a finding.
SLA clocks that escalate on their own, route to the right tier, notify the account owner, and record every escalation so the pattern behind them can eventually be fixed.
None of these is clever. All of them are the difference between an estate that can be changed and one that can only be replaced.
Workflows carry a purpose description; variables carry a name that reveals their type; every action label says what it does rather than what kind of action it is. A canvas of twenty actions labelled with their default names is unreadable within a month.
Validation, routing, notification and write-back each become a labelled block. The workflow then reads as a sequence of intentions rather than a wall of steps, and a reviewer can find the part they need to change.
Form rules and guard clauses catch bad data before the process starts moving. Catching it at step nine means unwinding eight steps of side effects, which is a far more expensive class of problem.
We check what the collection actually contains at real volume, keep iteration counts to the minimum, avoid calling out to a throttled service inside a loop, and pause the loop where the platform's own guidance says to. History logging inside a loop is removed.
Every action that touches an external system has a defined behaviour on failure: retry with a bound, escalate, compensate, or stop and notify a named owner. Captured errors that nobody is told about are worse than failures, because they look like success.
Tasks carry enough context to be decided without opening another system, due dates are realistic, reminders exist, and there is a reassignment path for when the assignee is unavailable. Approval queues die from friction, not from logic errors.
Six near-identical workflows for six regions become one workflow driven by configuration. That is one place to fix a defect instead of six, and five fewer chances for the regions to quietly diverge.
These are the failures we see in inherited estates. Each has a design answer, and each answer costs almost nothing if it is decided before the build rather than after the incident.
| Failure mode | How it shows up | Design response |
|---|---|---|
| Transient API failure | An instance stops mid-process because a connected system briefly returned an error or a timeout. | Bounded retry with a delay, distinguishing retryable responses from permanent ones, and a defined give-up path that notifies rather than sits. |
| Throttling under volume | Fine in testing, failing in month-end. Calls are being rejected because too many were made too quickly. | Move calls out of loops where possible, batch where the API supports it, pause between iterations, and respect the documented limits rather than discovering them. |
| Approver unavailable | A task sits for two weeks because the assignee left, is on leave, or is also the requester. | Due dates, reminders, an escalation path with a defined timeout, delegation rules, and a routing rule that never assigns a task to its own requester. |
| Partial multi-system write | The CRM was updated, the ERP was not. Two systems now disagree and nobody knows which is right. | Order writes so the authoritative system goes last where possible, and define a compensating action — plus a reconciliation check that flags the disagreement. |
| Self-triggering loop | A workflow updates a record, which re-triggers the same workflow, which updates the record. | A trigger condition that excludes the workflow's own service identity or its own field changes, plus an instance-count alert that catches it in test. |
| History flooding | Instances slow markedly and the history is unusable, because logging was placed inside a loop that now runs thousands of times. | Log outside loops, log decisions rather than iterations, and keep the history readable enough to be used during an incident. |
| Silent stall | Nobody notices an instance has stopped until a customer asks. There is no alert because the error was captured and discarded. | Every captured error routes to a named owner, and a stalled-instance check runs on a schedule so the process monitors itself. |
We test these deliberately before go-live rather than waiting for production to find them. If you are auditing an estate you already have, the companion piece is 10 common Nintex workflow mistakes.
These overlap, and the overlap is where money gets wasted. The honest version: pick by the shape of the problem, not by what you already own a licence for.
| Approach | Strongest when | Weakest when | Typical role in one process |
|---|---|---|---|
| Nintex workflow | The process crosses systems, needs human decisions in the middle, runs for days, and must leave an audit trail. | The work is a single-record field update inside one platform that the platform can already do natively. | The orchestrator — it holds the state of the process and decides what happens next. |
| Robotic process automation | A system has no usable API and the only interface is the screen a person would click. | An API exists. A bot that automates an available API is a brittle solution to a solved problem. | A participant — one step the orchestrator calls, and expects to fail occasionally. |
| Native CRM automation | The logic is entirely inside one platform, on its own objects, with no human queue outside it. | The process needs to wait days for a person, or touch systems the platform does not own. | The local rules — validation and record-level behaviour inside the system of record. |
| Integration platform | High-volume, system-to-system data movement with transformation and no human step at all. | The process is mostly human judgement with a little data movement around it. | The pipe — moving and reshaping data underneath the process rather than running it. |
Most real processes use two or three of these. The architectural question is which one holds the state — and the answer should be exactly one of them. Nintex process automation covers orchestrating across them.
For a single self-contained workflow, often you do not. Low-code genuinely removes the build barrier. What it does not remove is the design question — trigger conditions that do not recurse, loops sized for production volume, error handling that distinguishes transient from permanent failure, and a naming convention the next person can follow. Those are architecture decisions, and they are the ones that decide whether workflow one hundred is as easy to change as workflow one. Many of our engagements are as much about coaching an internal team through those patterns as about building for them.
By where the ownership boundary sits and where the change requests will come from. If two parts of a process are owned by different teams and change on different cycles, they should be separate workflows with a clean handoff, so one team's change cannot break the other's. If the logic is one process that varies only by region, product or value band, that is one parameterised workflow, not five copies. The failure mode to avoid is the copy: near-identical workflows drift apart, and a defect fixed in one silently survives in the other four.
Yes — long-running, state-holding processes are exactly what a workflow engine is for, and they are where it beats a scripted integration. The design considerations change, though. Long-running instances need to tolerate the fact that people leave, org structures change, and approval thresholds get revised mid-flight. We handle that with role-based rather than person-based assignment, configuration read at the point it is needed rather than captured at start, and an explicit decision about what happens to in-flight instances when the workflow is updated.
Yes, and we treat the form as part of the workflow design rather than a wrapper around it. The form is where data quality is won or lost: conditional visibility so people see only what applies to them, validation and lookups that prevent bad values instead of reporting them later, and repeating or table sections where a process genuinely handles multiple line items. Where the interface needs to go beyond what a form should carry — a dashboard, a queue view, a guided multi-step experience — that is customization work, and we will say so rather than overloading a form.
Three layers. Functional testing walks every branch, including the ones nobody expects to be taken. Negative testing deliberately breaks things — disconnect the integration, submit malformed data, let a task expire, remove an approver mid-process. Volume testing runs the loops against a realistic collection size rather than three test records. The negative layer is the one most often skipped, and it is the one that predicts what production will do.
Not on principle. A workflow that runs reliably, is understood by someone still employed, and nobody needs to change is fine as it is. The case for rework is specific: it fails intermittently, it cannot be changed without fear, it duplicates four others, or it is about to be extended. We would rather apply the standards to what you build next and remediate selectively than bill for rewriting things that are quietly working. That triage is what workflow optimization covers.
A working session on one real workflow tells you more than any proposal. We will look at the trigger conditions, the loops, the task routing and the failure paths, and tell you what we would change — whether or not you then hire us to change it.
Workflow design that assumes production will be harder than the demo
