Workflows

Workflows let you automate what happens after a form is submitted. Use them for approval routing, team follow-up emails, webhook handoffs, and response audit trails.

Workflows are configured from the Workflows tab in the form creator. The canvas starts with a fixed Form Submitted trigger, then you connect approval, email, and webhook blocks to define the path each submitted response should follow.

Plan requirements

You can design workflow drafts on any plan. Publishing workflows that run approvals, emails, and webhooks requires the Premium plan.

Published workflows keep running for new submissions until you unpublish them. If your organization later changes plans, existing published workflows continue to run, but publishing new workflow changes requires current Premium access.

Workflow publishing

Form publishing and workflow publishing are separate:

• Form publishing controls the form version respondents see.
• Workflow publishing controls the automation version that runs after a response is submitted.

Workflow draft changes are autosaved when the configuration is valid. If the draft differs from the latest published workflow, the Workflows tab shows an alert so you can publish or revert the draft.

Use the workflow status control in the Workflows tab header to publish, unpublish, or see the current published version. Unpublishing a workflow stops it from running on future submissions.

Workflow versions

Each published workflow is saved as a version. Open Workflow History from the Workflows tab to review published versions, preview their block configuration, and restore an earlier version when it is still available under your plan’s version history window.

Workflow runs are tied to the workflow version that started them. If a run is still active and a newer workflow version is available, you can upgrade the run from the response workflow panel after confirming the action.

Blocks

Form Submitted

The Form Submitted trigger is fixed. There is one per workflow, and it represents the moment a submitted response should start the workflow.

Approval

Approval blocks ask one or more team members to review a submitted response. Any selected approver can approve or reject the step.

Approval blocks can include:

• Approvers — the team members who can make the decision.
• Approval form — an optional SurveyJS form shown to the approver during review.
• Response locking — an option to lock the response after the approval decision is made.

When an approval is assigned, Formspace can email the approvers. Approval email content can be customized with the same variable insertion approach used by email notifications. Approvers must be verified members of the organization.

Approvers see approval cards on the response. Pending approvals assigned to you include a review action. Pending approvals assigned to others show who they are waiting on. Completed approvals open a read-only view of the approval form data.

Approvers can undo a decision when they need to correct it. The workflow event timeline records the decision and the undo action so the audit trail remains intact.

Send Email

Send Email blocks send a templated email as part of the workflow.

Recipients can include verified organization members and, when the response is not anonymous, the responder. Email content supports the same customization and variable insertion pattern used by standard notification and thank-you emails.

Completed Send Email steps can be re-triggered from the workflow timeline when you need to resend the email.

Call Webhook

Webhook blocks call an external endpoint as part of the workflow.

Webhook blocks can include:

• URL and method — the endpoint Formspace should call.
• Headers — custom headers to send with the request.
• Body template — a JSON payload template with workflow, response, respondent, and answer variables.
• Payload preview — a preview of the generated payload before publishing.

Completed webhook steps can be re-triggered from the workflow timeline when you need to call the endpoint again.

Connections and conditions

Connections define which block should run next. A connection can always continue, or it can include a condition that decides whether the path should be followed for a specific response.

Conditions use the same expression style as form logic. They can reference response answers, respondent details, form details, and workflow context. For example, a workflow can route high-value requests to an approval block, skip an email unless a checkbox was selected, or call a webhook only when a department answer matches a specific value.

Formspace validates condition variables against the form schema used by the workflow. If the condition references a question that only exists in an unpublished form draft, publish the form changes before publishing the workflow. The workflow run dialog and timeline show condition evaluations as Matched, Skipped, or Error, including useful variable values for debugging.

Variables

Workflow email content, approval forms, and webhook templates can reference response data so automations stay connected to the submitted answers.

Use the variable insertion controls where available rather than typing tokens by hand. This helps avoid invalid variables and makes it clearer which response, respondent, form, or answer values are available in the current context.

Viewing workflow runs

After a response triggers a workflow, the response view shows workflow status and approval cards. Open View Run to inspect the run.

The Workflow Run dialog includes:

• Canvas view — shows the workflow blocks and connections, with completed, running, and failed steps highlighted.
• Timeline view — shows response activity and workflow events in chronological order.
• Step details — shows timestamps, useful result summaries, errors, and re-trigger actions where supported.

Timeline timestamps are shown in UTC.

Responses and submissions table

Workflow data appears throughout the response management UI:

• The Responses sidebar item shows a count when approvals are waiting for you.
• The global Responses page includes a quick Waiting on me filter and can also filter by workflow and approval state.
• The response panel and full response route show workflow status, approval cards, approval form data, and the workflow run dialog.
• The submissions table can include workflow version and workflow status columns.
• Approval columns are grouped by approval block so related status, reviewer, decision, and approval form data columns can be expanded, collapsed, hidden, moved, and exported together.

PDFs

Response PDFs include workflow information when it adds useful review context:

• If a response has workflow approvals, the workflow status appears in the page header.
• Completed approval blocks appear as natural response sections with the approval name, reviewer summary, and approval form fields.
• The optional timeline page includes response activity, workflow events, and the PDF generation event.

Timeline timestamps in PDFs are shown in UTC.

PDFs attached to respondent thank-you emails exclude workflow approval details and timeline events. Those sections are intended for internal review, exports, and team notification emails.

Practical tips

• Keep the first workflow simple: start with one approval or one email action, then add branches after testing the happy path.
• Use approval forms for reviewer-specific information instead of adding office-only fields to the respondent-facing form.
• Keep webhook payloads focused on the fields the receiving system needs.
• Publish workflows only after checking the draft alert, validation state, and preview details for each block.

What’s next?

• Publishing & Sharing — Understand how form publishing differs from workflow publishing.
• Managing Responses — View workflow runs, approvals, exports, and PDFs after submissions arrive.
• Subscription & Billing — See the Premium plan requirement for publishing workflows.