Skip to main content

I can't publish — fixing Process Validator errors

Separate editor validation, server release checks, and post-release follow-up problems.

Written by Alex Merkin

Start with the exact message and the current editing mode. Correct one issue at a time, wait for saving, then check again. If you are learning the editor, you do not need to publish the exercise: keep it as a draft and use Preview.

Publishing can stop at several stages. First identify whether you cannot open Publish, the editor lists configuration errors, the server rejects the release, or a follow-up action fails after release.

If Publish is unavailable

Check whether the workflow is editable and whether the selected version is already released. Read-only or locked state can disable the header button. It is not disabled solely by the Process Validator's error count.

Inspect the Process Validator

Open the floating badge. Filter errors, warnings, and information as needed. Use an issue's navigation when available to reach the relevant step, route, or trigger.

Errors block the release flow. Warnings call for review; they are not a guarantee that server validation will succeed.

Process Validator with a Standard Time message

Process Validator lists a Standard Time message in this example. Read the exact message and identify its category before changing settings; a message is not automatically a blocking error. Recheck after correcting the relevant configuration.

Examples of actual configuration issues

Root step is not defined: select the intended starting step, open Process, and enable First Step.

Multiple root steps: keep First Step on only the intended entry step.

Empty workflow: add at least one executable step or reference and complete its configuration.

Workflow connection cycle: inspect the arrows for a loop in the workflow's connections. This message is not simply a description of workflow A referencing B.

Unassociated or missing reference: open the reference step and select the intended available workflow.

Incomplete trigger: check the action's required variable, form, table, webhook, message, or other settings. Also check event compatibility.

Unknown/deleted field or variable: inspect the identified condition, formula, or instruction and replace the reference with a valid one.

Do not add a made-up configuration to silence an error. Correct the actual process definition.

Show/Hide and routing restrictions

Routing and Logic display their own restrictions when a step combines incompatible outgoing routes and display logic. Resolve the configuration there. Do not expect a validator message literally named “both Display Expression and conditional routing.”

Server release errors

The publish modal can report issues beyond local validation, including reference-variable incompatibilities or conflicting workflow type/Part mappings.

Follow the specific error. Use Manage Variables when offered and appropriate; some variable mismatches must be fixed in the child workflow.

After a partial follow-up failure

If the main workflow releases but a parent republish or related-form action fails, inspect the resulting version state first. Do not assume the release rolled back.

For support, record the workflow/version, exact message, failing stage, and a screenshot. Include save-error diagnostics only when the problem is actually a failed save.


Did this answer your question?