Publish and share an app

Publishing creates a runnable version from the app's saved projects and configuration. Saving a file changes the draft; publishing changes the version that shared forms, widgets, and configured triggers use.

Complete the relevant simulation checks first. Publishing applies to the app's groups together, so review every group before publishing an app containing more than one workflow.

Confirm the intended server files, widget client files, form definitions, and group settings are saved. Check each form or widget's Scope and each trigger group's event or schedule selection. Review server permissions, outbound hosts, secrets, timeout, and memory limits.

Keep draft and publication state distinct. A simulation may be running a new draft while visitors still use the previous published bundle. Conversely, changes to the app-managed API key's permissions can affect a published version immediately; publication is not a complete isolation boundary for all settings.

Open the app Overview and choose Publish. For an app that already has a published version, use Publish update. Wait for validation, bundle generation, and the publication result.

The publisher validates and builds the required server and client bundles, creates the published group definitions, and stores a new version number with its publication time. The Overview's published version and publication history should reflect the new release.

If publication fails, inspect the reported validation or build failure. Do not assume the failed draft became live. Recheck the published version before telling users to reload or repeating a release action.

From the Overview, use the intended group's share action. Sharing is available for Form and Widget groups. Schedule and Record changes groups are triggered server workflows and do not have a visitor interface to embed.

The share dialog supplies a link and embed options for that group. Copy the generated URL or embed code rather than assembling it from the app ID. The share URL identifies the group, and opens its published version.

Copy the link from the intended organization and group. Open it to verify the published version and access settings before adding it to your website.

Open the actual shared link and test the complete interaction. For the generated widget, choose Calculate and confirm the server result. For the reference form, submit a synthetic reference and confirm the returned message.

Check both an allowed caller and a caller the Scope should reject. Owner simulation does not verify public, contact, or admin access. For a PIN-protected group, test a missing and incorrect PIN as well as the correct one.

When embedding, test the resulting page on a narrow screen and verify that the frame has enough space for validation messages and the success result. Do not expose the app-managed credential in the embedding page; the runtime handles app actions.

Edit and save the draft, simulate the changed behavior, then choose Publish update. Verify the new version and repeat the shared-link check. The same group can retain its share identity while its published implementation changes.

Review all groups in the release. A publish operation is not limited to the currently selected source file or the group most recently simulated.

If a change requires a data migration or external-service update, plan that separately. Replacing a bundle does not automatically migrate your app database or undo previous API side effects.

Use the app's unpublish action when you need to withdraw the published app. The draft remains available for editing and later publication. Verify that the shared group is no longer runnable, and consider any work already running or queued separately.

To recover earlier source, use File history for the relevant files, review the related group and server settings, simulate the restored draft, and publish a new update. Reverting one file is not a full application rollback and cannot reverse records or third-party actions changed by a previous run.

Record the published version, test inputs, and observed outcomes with your release. That makes later debugging much more precise than referring to “the latest code.”