The form takes a minute. The approval takes eleven days.

A multi-page form is still one person, in one sitting, filling in one thing. A Workflow is a process built in FormAssembly's Workflow Builder from separate steps — forms completed by different participants, approval steps where someone decides, conditional steps that route down different paths, and connectors that run at a particular point rather than at the end. The practical difference is time and ownership: a workflow can pause for days waiting for an approver, and each step can belong to a different person, which a multi-page form cannot do.

An approval step names the form response requiring approval, who decides, and what happens next. The decision produces two paths — approved and denied — and both are designed rather than one being an afterthought. Around that, the choices that matter are how many levels of approval a request needs, whether a threshold routes it to a more senior approver, what happens when the approver does not respond, and whether approval by any one of several people is sufficient or all of them must agree. Those are policy decisions we get written down before anything is built.

Yes, and this is usually where the real value is. A conditional step routes the workflow down one or more paths based on rules you define against the submitted values, so a request can skip approval entirely under a threshold, go to a team lead in a middle band, and escalate above it. Modelling the policy this way means the rule is enforced rather than remembered — and when the policy changes you change the ruleset instead of retraining everyone.

Whatever you design, which is the point — the default is that the request waits indefinitely and nobody notices. Escalation and reminder design is a distinct piece of work: how long a step may sit before it is chased, who is reminded, when it escalates past the original approver, and whether a delegate can act during an absence. Most approval processes that fail in practice do not fail on the decision, they fail on the silence before it.

At the step where the data becomes true, not at the end of the process. Workflow-native connectors let a record be created or updated at a specific step, so a request can appear in Salesforce when it is raised, be updated when it is approved, and trigger downstream work only on the approved path. Putting every connector at the end is the common shortcut, and it means the CRM knows nothing about a request until the process has already finished — which removes any possibility of reporting on work in progress.

Yes — a step can be completed by an external participant such as a supervisor, referee, guarantor, vendor or partner. The design questions are about access rather than routing: whether that participant needs to authenticate before opening their step, what they are allowed to see of what has already been submitted, and how long their link remains valid. Those are decisions to make deliberately, particularly when the earlier steps contain data the external participant has no business reading.

By reporting on the process, not just the submissions. Once a process is modelled as workflow steps rather than email, you can answer how long each step takes, where requests stall, how many are denied and why, and which approvers are the bottleneck. That was almost certainly unanswerable before, because the decision was happening in an inbox. We treat the cycle-time baseline as part of the delivery, so the improvement is measured against your own process rather than asserted.