Publish and operate a form

Publishing makes a form available through its public link. Treat the first publish as a short release checklist, not only a button press.

The goal is to know that the right form is live, the team can review submissions, and supported follow-up can be monitored or recovered.

Publish checklist

Before publishing:

• confirm the title and description are user-facing
• preview the form at mobile and desktop widths
• submit a test response
• confirm the response appears in the app
• confirm supported follow-up delivery is correct for the team
• confirm who owns review and recovery after launch

Share the public link

After publishing, copy the public form link and place it where users already expect to find the workflow. Common places include a website CTA, a support article, a job post, an onboarding email, or an internal request page.

Use one canonical link per workflow. If a form replaces an older process, update old pages and messages so users do not split responses across multiple channels.

Change a live form carefully

Small copy edits are usually safe. Structural changes need more care because they can affect how new submissions compare with older ones.

Before changing a live form:

• check whether existing responses depend on the current fields
• avoid renaming fields in ways that make exports unclear
• add new optional fields before making them required
• test the public form again after publishing the change

When the workflow changes significantly, publish deliberately instead of turning the old form into a different process without review.

Operate after launch

After the form is live, set a review habit:

• check new submissions on the cadence the workflow needs
• confirm the source form context before acting
• monitor supported delivery state
• retry recoverable failed follow-up
• acknowledge failures that were handled manually
• export or audit records when the team needs evidence

Next: Review submissions and Delivery recovery.