Jotform Workflow exists because a form on its own answers only half of a question. The submission arrives, and then somebody has to decide something about it. Approve the expense, accept the application, sign off the request, route it to whoever handles that category. Building that out of email alerts and conditional logic is possible and miserable, which is what the workflow builder replaces.
What follows is what it actually contains, where the boundaries are, and which parts of the work stay manual afterwards. The last part is the one worth reading carefully, because a workflow is a very good shape for some intake work and the wrong shape for the rest of it.
Where it lives and what a workflow is made of
A workflow starts from a form. In the Form Builder you open Settings, choose Workflows in the left panel, and Create Workflow opens the workflow builder in a new tab. The canvas is drag and drop, and the elements come in two groups.
The Basic elements are the things that happen. Form adds a follow up form to the flow. Payment Form collects money at a step. Email sends a message to keep people informed. Task assigns a specific task to a specific assignee. Approval defines outcomes for a decision. Approve & Sign requires the approver to add a signature when they decide. Team Approval requests a decision from a team rather than a person. Sign Document collects signatures. PDF sends a PDF of the data gathered so far. Flow Report generates a report on an ongoing or completed process.
The Logic elements are how the flow bends. If/Else Condition routes on a form answer and supports two outcomes. Conditional Branch routes to as many branches as you define. Split Branches runs paths in parallel. Merge Branches brings parallel paths back together. End marks a branch as finished, and can be set to terminate the whole flow instead.
There is also a Test Run feature that walks the flow step by step before it goes live, which is more useful than it sounds. Branching logic that reads correctly on the canvas frequently does something else in practice, and finding that out with a real submission from a real person is the expensive way to learn it.
What the approval element actually does
The Approval element ships with Approve and Deny as default outcomes. You can add more outcomes, which matters more than it first appears: a lot of real decisions are not binary, and "send back for more information" is a genuinely different outcome from a rejection.
Multistep and parallel approvals are both supported. Multistep is the sequence where a manager approves and then finance approves. Parallel is where two approvals happen at once and the flow waits. Group Approval handles the case where several people can decide and you need a rule for what counts as done, which is the situation that otherwise turns into a stack of approval elements and conditions nobody can read six months later.
Approve & Sign is the same decision with a signature attached, for anything that needs a record of who authorised it rather than just a status change.
Whether your approvers need a Jotform account
This question decides feasibility for a lot of teams, and the answer has two halves.
Approval and Approve & Sign have a Require Login setting, enabled by default, which you can turn off per element. With it off, an approver who has no Jotform account can act. They are taken from the email to an approver action page where they approve or deny.
The limit is what they cannot do. Approvers without an account do not get access to the form's Inbox, so they cannot browse pending items, see history, or pick up work that was not emailed to them. And reassigning a task to someone else happens on the Inbox page, which requires signing in, so a stand in who needs to hand something on has to have an account.
That interacts with the pricing. Jotform's Starter, Bronze, Silver and Gold plans are each listed as one user, and multiple users arrive only on Enterprise. So the workable arrangement on an individual plan is one account holder who builds and owns everything, plus approvers who act through emailed links without accounts. That works cleanly for approvals and does not work at all for shared handling of a queue, which is a different job that happens to start the same way.
The volume underneath it
A workflow runs on form submissions, and submissions are what Jotform meters. As of September 2026 the published monthly figures are 100 submissions on the free Starter plan, 1,000 on Bronze at 39 USD per month, 2,500 on Silver at 49 USD per month, and 10,000 on Gold. Form counts are capped too, at 5, 25, 50 and 100 respectively.
Worth noting for workflow design specifically: if your flow includes a follow up Form element, the respondent completing it is another submission. A process built as three chained forms consumes three times the allowance of a process built as one form with branching. That is not a reason to avoid chaining, but it is a reason to count before building.
What it leaves to you
A workflow is a good model for a decision with a known shape. Here is where intake work falls outside that shape, and what happens in each case.
| The work | Inside the workflow | Left to you |
|---|---|---|
| A decision with defined outcomes | Approval, multistep, parallel, group rules | Nothing much |
| Routing by category or amount | Conditional Branch, If/Else | Nothing much |
| Telling people what happened | Email element, PDF, Flow Report | Wording that fits the case |
| A back and forth conversation | Not modelled | The whole exchange, in a mail client |
| Someone taking ownership of a queue | Task assignment per item | Seeing and sharing the queue, on individual plans |
| The exception that does not fit the flow | Not modelled | Handling it outside the workflow entirely |
The fourth row is the one that surprises people. A workflow can send an email. It cannot receive the reply. When an applicant answers the message with a question, that answer lands in a mailbox, and the exchange continues there while the workflow sits waiting at a step. By the time a decision is made, the reasoning for it lives in one person's inbox and the record in the workflow shows only the outcome.
For an expense approval that is entirely fine, because there is rarely a conversation. For recruitment, enquiries, grant applications or support intake, the conversation is most of the work, and a tool that keeps the answers, the history and the reply on one screen is solving a different problem from the one a workflow builder solves.
Where the integrations fit
The Integrations tab connects a workflow to Airtable, Asana, Box, Campaign Monitor, ClickUp, Constant Contact, Dropbox, Egnyte, Google Calendar, Google Drive, Mailerlite, Microsoft Teams, monday.com, OneDrive, Quickbooks and Slack.
These are how a workflow hands off. Data goes out to the system that owns the next stage, a notification goes to a channel, a file lands in storage. Used well, this is what stops a workflow from trying to be everything.
Used badly, it is how a process ends up spread across four tools with no single place that answers where a given request currently stands. The question worth asking before adding an integration is which system is the record for this piece of work. If the answer is "both", the process will drift, and the drift is only discovered when someone asks about a request from three weeks ago.
Choosing between a workflow and a queue
These are two different shapes and most teams need to know which one they have.
A workflow suits work with a defined beginning, defined decision points, and an end. Expense claims, leave requests, purchase approvals, document sign off, event budget authorisation. The path is known in advance, the same every time, and the interesting question is who decides and in what order. Jotform Workflows is built exactly for this, and the 200 plus templates in its library are almost all of this type.
A queue suits work where items arrive, someone picks them up, something is discussed, and the end is not predictable. Job applications, customer enquiries, support requests, membership applications. The interesting questions are who owns this one, what state is it in, and what has already been said to this person. Comparing that against the shape of your own intake is usually more decisive than comparing feature lists.
Plenty of teams have both, and plenty of tools do one well and the other adequately. The mistake is assuming that because both start with a form submission, one tool should obviously handle both.
Building a workflow that still works in six months
Most workflows are correct on the day they are built. The trouble starts later, when the process changes and the canvas does not. A few habits keep that gap small.
Write the process down before opening the builder
List every decision, who makes it, and what happens on each outcome, in plain sentences. If a step cannot be described in one sentence, it is probably two steps, or it is a conversation rather than a decision. Doing this on paper first makes the canvas shorter, and it shows early which parts will never fit a flow and need a different home.
Name the exits, not just the happy path
Every Approval element needs a clear answer for Deny and for any extra outcome you add. A denied request that simply ends leaves the requester guessing. An Email element on each exit, with wording that says what was decided and what the person can do next, removes most of the follow up questions that otherwise arrive by mail and sit outside the workflow.
Keep one owner for the design
Because building and editing happen under the account that owns the form, changes tend to collect around one person anyway. Make that explicit. When the policy changes, for example a new spending threshold or an extra sign off, one person updates the branch, runs Test Run again, and records what changed. Workflows edited by whoever happened to notice a problem are the ones that end up with two conditions contradicting each other.
Review the flow against real outcomes
Every few months, pick a handful of recent submissions and trace what actually happened to each. If several needed handling outside the flow, that is a signal. Either the flow is missing a branch, or that category of work belongs in a queue rather than a workflow.
What to change first
Work out whether your process is a decision with a known path or a queue that needs owners and replies, because that distinction decides everything else. If it is a decision, map it in a workflow builder and use Test Run before it goes live. If it is a queue, look for a tool where each response carries its own owner, status and reply history, and see that working on real responses before committing, for example with Halict.
Q1. Do approvers need a Jotform account to approve something?
Not necessarily. The Approval and Approve & Sign elements have a Require Login setting that is on by default and can be turned off, after which an approver without an account can act from a link in their email. They will not have access to the form's Inbox, and reassigning a task to someone else requires signing in, so a stand in who needs to hand work on does need an account.
Q2. Is Jotform Workflows included on the free plan?
Workflows can be built without paying, but the underlying submission limits still apply, and on the free Starter plan that is 100 submissions a month across 5 forms. A workflow that chains follow up forms consumes a submission for each one, so a three step process uses the allowance three times faster than a single form with branching.
Q3. What is the difference between If/Else Condition and Conditional Branch?
If/Else Condition routes a flow on a form answer and supports two outcomes, true and false. Conditional Branch lets you define as many branches as the process needs and send the flow down whichever one matches. Split Branches runs paths at the same time and Merge Branches brings them back together.
Q4. Can a workflow handle the back and forth with an applicant?
Not directly. The Email element sends messages out, but replies arrive in a mailbox rather than in the workflow, so the conversation continues outside the flow while the step sits waiting. For processes where the exchange is most of the work, such as recruitment or enquiries, a tool that keeps the reply next to the response is a better fit than an approval builder.
Q5. How do you test a workflow before using it on real submissions?
Use Test Run, which walks through the flow step by step and shows how data moves between elements. This is worth doing on anything with branching, because logic that reads correctly on the canvas often behaves differently in practice, and discovering that with a real applicant's submission is the expensive way to find out.