# Publish checks

What formbase checks before your form goes live, which findings block publishing, and how to clear each one.

## Publish checks

Every time you edit, formbase re-reads your form and lists what would not work once it is live. Errors stop the publish; warnings let it through after you confirm.

<h2 id="where">Where the check lives</h2>

<p>
  The <strong>issue indicator</strong> sits beside the Publish button in the top toolbar. It is a traffic light for the whole form: green
  with a check mark when nothing is wrong, amber with a triangle when there are warnings, red with a cross when there are errors. Click it
  to open the list, grouped under <strong>Errors</strong> and <strong>Warnings</strong>.
</p>
<p>
  Each entry shows the finding and, underneath it, the action that clears it. Clicking the entry takes you there — into the editor and
  scrolled to the block, into the right tab of form settings, or into the Translate tab for that language. The list updates as you type, so
  you never have to press Publish to find out.
</p>

<h2 id="errors-vs-warnings">Errors and warnings</h2>

Review needed</strong> dialog lists every warning with the note “These may not work as expected once your form is live.” Cancel and fix them, or press <strong>Publish</strong> to go ahead.',
      ],
    },
  ]}
/>

<p>
  For the settings warnings, pressing <strong>Publish</strong> in that dialog is the one-click fix: formbase applies exactly what each
  warning says it will do — switching off the password gate, the self-notification, the respondent confirmation, the reminder, or
  edit-after-submit, or clearing the redirect — and then publishes. Content warnings are never auto-fixed; the form publishes as it is.
</p>

<h2 id="content">Content and references</h2>

decision</code> is no longer a choice question carrying the approve, decline, and changes values, so requests finish with no outcome recorded.',
        'Insert a Decision question from the / menu.',
      ],
    },
  ]}
/>

<h2 id="logic">Logic and page jumps</h2>

<h2 id="field-keys">Field keys and hidden fields</h2>

<p>
  Field keys are the names your integrations and requests address — and so are the option, row and column keys under them. See{' '}
  <a href="/requests/field-keys">Field keys</a> for how they are derived and frozen; publish is where the collisions are caught. The publish
  dialog gathers every key this publish removes, renames or duplicates, at either level, under one heading:{' '}
  <strong>Keys changing in this publish</strong>.
</p>

requests.create</code> starts rejecting the key.',
        'Update the automations that use this key.',
      ],
    },
    {
      label: {
        title: '…“Company” now publishes as “company”. Set its field key back to “company_name” to keep them working.',
        description: 'Warning',
      },
      cells: [
        'Same warning, with the successor named: the field whose key you retyped, or the single new field standing where the old one was.',
        'Set the old field key on this field — the warning clears and the key carries on.',
      ],
    },
    {
      label: {
        title:
          'Option key “pro” of “Plan” will no longer exist after this publish. Integrations and requests that use it will stop matching that answer.',
        description: 'Warning',
      },
      cells: [
        'An option, row or column key the live version publishes is dropped by this one — you deleted the option or retyped its key. A workflow branching on <code>answers.plan == "pro"</code> stops matching, and a request prefilling <code>pro</code> is refused. When the option still exists the warning names the key it publishes as now.',
        'Set the old key back on the option in the Keys table, or update the automations that use it.',
      ],
    },
    {
      label: { title: 'Two options of “Plan” use the option key “pro”.', description: 'Error' },
      cells: [
        'Two options of one question — or two rows or two columns of one matrix — were typed onto the same key. Derived keys break their own ties with <code>_2</code>; only keys you set by hand can collide.',
        'Give each option its own key.',
      ],
    },
  ]}
/>

> ℹ️ **Removed keys are your call**
> <p>
>     Dropping a key is a warning, never an error. If you removed the field on purpose, publish anyway and update the automations that read
>     it.
>   </p>

<h2 id="payments-scheduling">Payments and scheduling</h2>

<h2 id="access-email">Access, email, and redirect</h2>

<p>These are the settings warnings, and every one of them is cleared by the dialog's Publish button.</p>

<h2 id="integrations-translations">Integrations and translations</h2>

<p>Form copy and email copy are counted separately, so the same language can appear once for each.</p>

<h2 id="server-refusals">Other reasons a publish is refused</h2>

<p>These are not issue-indicator entries — they appear as a red notification when you press Publish:</p>

<ul>
  <li>The form is in the trash. Restore it first.</li>
  <li>
    An email question has <a href="/building-forms/email-verification">respondent email verification</a> switched on and the workspace
    owner's plan is not <strong>Business</strong>. Upgrade, or switch verification off.
  </li>
</ul>

<h2 id="next-steps">Next steps</h2>
<div class="not-prose grid gap-3 sm:grid-cols-2">
  - [Field keys](/requests/field-keys) — How keys are derived, frozen, and safely renamed
  - [Version history](/building-forms/version-history) — Roll back a publish you regret
  - [Form settings](/building-forms/form-settings) — Access, notifications, and submission rules
  - [Translating forms](/building-forms/translating-form-content) — Clear the translation warnings
</div>