Engineering · Product · 7 min read

Long forms are workflows, and workflows need state

Some processes cannot be a single form. Visa applications, lending decisions, clinical intake, seller onboarding - they run to dozens of fields, involve documents and third parties, and take days. Built as a form with steps, they fail the first time someone leaves and comes back. Built as a workflow with state, they work.

The form model and where it breaks

The instinct is a wizard: a sequence of screens, validation on each, a record written at the end. It is easy to build and it survives exactly as long as everyone completes in one sitting.

They do not. What actually happens:

• Someone reaches step six and needs a document they do not have. They leave. Whether they come back depends entirely on whether the six steps are still there.
• They return on a different device, or after your deploy changed the step order.
• An answer at step two changes which steps are required at step seven.
• A third party - an identity check, a credit decision - resolves asynchronously, hours after the user has gone.
• Someone else must contribute: a co-applicant, a reviewer, a prescriber.

None of these are edge cases. In any process worth building this way, most journeys hit at least one.

Persist per step, validate per step

The first correction: each step commits when it is completed, and validation is scoped to the step rather than to the whole record.

That means the underlying record must be allowed to exist in an incomplete state, which fights the instinct to validate everything on the model. The resolution is that completeness is a property of the workflow, not of the record. The record holds what is known so far. The workflow knows what is still required.

Get this wrong and you end up unable to save a half-finished application at all, which is why so many long forms lose everything on a browser refresh.

Steps are data

The second correction: the sequence is not a hard-coded list of controller actions. It is data, derived from the current state.

This is what makes conditional paths tractable. If an answer at step two adds three steps, that is a rule evaluated against state, not a branch buried in a controller. It also means you can show honest progress - six of eleven, where eleven is computed for this applicant rather than being a constant that turns out to be wrong.

The practical benefit arrives on the day you reorder steps or add one. With hard-coded sequences, everyone mid-journey is now in an inconsistent position. With derived steps, they are simply somewhere in a slightly different sequence.

Waiting is a state, not a gap

When a step depends on something external - a verification, a document review, a decision by another party - the journey is not paused. It is in a state, and that state needs the same treatment as any other.

It needs to be visible to the user, to expire, to be chaseable, and to be reportable. "How many applications are waiting on us versus waiting on the applicant" is the first question anyone operating the process will ask, and it is unanswerable if waiting is just the absence of progress.

If your workflow cannot distinguish between abandoned and blocked, your operations team will do it manually in a spreadsheet.

Design for resumption

Coming back after two weeks is the normal case, not the recovery case. That means a durable link that survives session expiry, a landing experience that reminds them where they were and why they stopped, and reminders that are part of the workflow rather than a separate marketing concern.

The saved-progress email is frequently the highest-leverage feature in the entire product, and it is usually the last one built.

The operational half

Long workflows are always operated by someone as well as used by someone. Assume from the start that staff need to see where an application is, why it is stuck, and to intervene - correct an answer, reopen a step, override a check - with a record of who did it and why.

That is not an admin afterthought. In a regulated process the audit trail of interventions is part of what makes the process defensible, and retrofitting it means reconstructing history you did not keep.