Jotform Approval Workflow: How to Build One That Holds

Jotform's Approvals feature, also called the Workflow builder, is one of the more useful additions to the platform in recent years. It turns a form from a data-collection tool into a lightweight process engine. Submit a form, it routes to an approver, the approver approves or denies, the process moves forward. For PTO requests, expense approvals, document review, it works. But the edges are where things break. An approver goes on vacation. A conditional branch does not cover an edge case. An email notification fails. The workflow stalls and nobody notices. I spent five years inside Jotform and worked on the approval flow feature. Here is how to build one that actually holds under real use.

Setting up a single-approver flow

The simplest approval flow: one person reviews every submission. In the Form Builder, go to the Approvals tab. Click 'Create Approval Flow.' Jotform presents a visual editor with a Start node and an End node. Drag an Approver element between them. Select the approver by email address or by pulling from a form field.

The approver receives an email with a link to Jotform's approval portal. They see the submission data, and they click Approve or Deny. On approve, the flow moves to the End node. On deny, you can configure the flow to send a notification back to the submitter, end the flow, or route to a different step.

The single-approver flow is straightforward. The main thing to get right is the deny path. By default, a denial just ends the flow. If you want the submitter to know their request was denied, add an email notification step after the denial branch.

Multi-approver flows: any vs all

When you add multiple approvers to a single step, Jotform asks whether you need approval from any one of them or from all of them. This distinction matters more than it sounds.

Any approver

The flow advances as soon as any one approver clicks Approve. The other approvers are notified that the item has already been handled. Use this for distributed teams where any one person can act: a support team where any agent can approve a refund, a department where any lead can sign off on a schedule change.

All approvers

Every approver must click Approve before the flow advances. If there are three approvers, all three must approve. A single denial from any one stops the flow. Use this for processes that need full consensus: budget approvals that require both department head and finance sign-off, policy changes that need multiple stakeholder buy-in.

Conditional approval flows

This is where the workflow builder gets useful. Conditional flows route submissions to different approvers based on form data. Example: an expense form where expenses under $500 go to the team lead, expenses $500 to $5,000 go to the department head, and expenses over $5,000 go to the VP.

In the Approval editor, add a Condition element after the Start node. Set the IF criteria (e.g., 'Amount is greater than 5000'), then route each branch to a different approver. All branches must eventually reach an End node. If a branch has no endpoint, submissions on that branch sit in limbo.

Common patterns:

• PTO requests: route by department (Engineering approver vs Marketing approver), then by duration (1 day auto-approved, 2-5 days needs manager, 5+ days needs VP).
• Expense approvals: route by amount threshold, with optional escalation if the first approver denies.
• Document review: route by document type (legal review for contracts, HR review for onboarding docs, finance review for invoices).

The dead-end problem

The single most common mistake in Jotform approval workflows: a conditional branch that does not cover all possible values. You build branches for Department = Sales and Department = Support. Someone submits with Department = Operations. There is no matching branch. The submission enters the flow, hits a dead end, and sits there forever. No notification. No escalation. It just exists in the approval queue with no status change.

This is especially easy to miss because it only happens when real data does not match your expected values. During testing with a few controlled submissions, everything works. In production, someone types a department name that does not match your condition, and the flow breaks silently.

The timeout problem: when approvers do not respond

Jotform's approval flows do not have built-in timeout or auto-escalation. If an approver ignores the approval email, goes on vacation, or leaves the company, the submission stays in 'Pending' indefinitely. There is no automatic reminder, no escalation to a backup approver, no timeout that auto-approves or auto-denies after a period.

You can build manual timeout handling by adding a condition-based reminder system. The approach:

1. After the approver step, add a 'Wait' element set to a specific duration (available in Jotform's workflow elements).
2. After the Wait, add a condition that checks whether the approval status is still Pending.
3. If Pending, route to an escalation step: a different approver, a notification to an admin, or an auto-approve action.

This is not as robust as a dedicated SLA engine, but it covers the most common case: the approver who is simply out of office. For more complex timeout needs (business-day calculations, multi-level escalation), you would need to push the approval data to an external system via webhook and handle the logic there.

Email notifications at each step

Every approval step can send an email notification. By default, Jotform sends an email to the approver when a new submission arrives at their step. You can also add emails for: the submitter when their request is approved, the submitter when their request is denied, a third party (e.g., HR) when a specific type of request is approved.

The email templates are basic. You can include form field values using the curly-brace syntax (e.g., {name}, {department}, {amount}). You cannot include conditional content in the email body. You cannot format it as a rich HTML document with dynamic sections. If you need a polished approval email, send the notification to Zapier or a webhook and generate the email from your own system.

Testing approval flows without sending real emails

Do not test approval flows with real approvers on a production form. The emails are real. The approvals are real. If you submit a test PTO request, the approver gets a real email, and if they approve it, it shows up in the approval log. That is messy.

Instead, duplicate the form. Change the approver email addresses to test addresses you control (use a service like temp-mail or a shared test inbox). Submit through every branch. Confirm that each branch routes to the right approver, that the approval/denial actions work, and that the end-of-flow notifications fire.

Specifically test: the 'else' branch with an unexpected value, the deny path, the multi-approver 'all' scenario where one approver denies, and the timeout behavior if you have Wait elements configured.

When to use Jotform Approvals vs external tools

Jotform's approval builder works for straightforward, form-driven approval processes. If your process is: form submission, one or two levels of approval, done, use Jotform. It keeps everything in one place, the audit trail is in the Jotform dashboard, and there is no extra tooling to maintain.

Move to an external tool when:

• You need more than two levels of approval with complex branching logic. Jotform's visual editor gets hard to read past about 8 nodes.
• You need real-time SLA tracking, business-day-aware timeouts, or multi-level escalation chains.
• Your approval process involves systems outside Jotform (update a CRM record, create a ticket, modify a database) as part of the flow, not just after it.
• You need delegation (approver A delegates to approver B with a single click). Jotform does not support this natively.

For those cases, Zapier or a custom webhook pipeline gives you more control. The tradeoff is complexity and cost. Most teams do not need it. Most teams just need: form, approver, notification, done. Jotform handles that.