How do I publish a workflow as a web app?

To publish a workflow as a web app in AI Flowi Workflow, select a saved workspace workflow and choose one of five app types: chat, form, dashboard, portal or custom. Set its address, access and branding, then review and publish. Test the workflow and the visitor page before sharing its address.

By Ai Flowi · Technical review: Janice Lee, Technical Support, Ai Flowi.

Published 7 October 2026 · Updated 9 October 2026

For publishing features and access modes, see the Publish feature page.

Product: AI Flowi Workflow by Ai Flowi · Task: Publish a configured workflow · Components: Existing workflow; no extra publishing component

When to use this

Use publishing when people need to run a workflow through a web address. Available app types are chat, form, dashboard, portal and custom. The visitor relay accepts text input and returns chat or text output; an app type does not change that contract.

Before you start

• Save and test a workflow in the workspace that will own the app.
• Check that your workspace has publishing access and that your account has permission to manage published apps.
• Check your workspace’s published-app quota.
• Prepare a brand name and heading. Prepare a logo, favicon and suggested prompts if you want to use them.
• Choose public, login-required or private-link access. Login-required users need permission to view publishing in the app’s workspace.
• For a custom domain, have its administrator configure the supplied DNS proof and ensure TLS is deployed.

Steps

Add the workflow and app type

Add: Open the publishing wizard from the workflow’s Publish Web action, or start a new app in the published-app list.

Set: Select the saved workflow and choose chat, form, dashboard, portal or custom.

Connect: The app is linked to the selected workspace workflow; this step does not add or change component ports.

Test: Confirm the selected workflow is the one you tested.

Expected: The wizard carries that workflow and app type into the address step. After an app draft exists, its workflow and app type are locked.

Set the address and visitor access

Add: Choose the supplied app address or a custom domain.

Set: Enter the address name and page title. Choose public, login-required or private-link access, and confirm any requested change that broadens access.

Connect: For a custom domain, use the supplied CNAME target and TXT verification token. The CNAME must point directly to the supplied target. Have the domain administrator set the records and complete DNS verification before publishing.

Test: Review the saved address, access mode and domain verification result. Keep a newly issued private link safe; it is shown once.

Expected: The draft has its address and access settings saved. A custom domain must be verified before it can pass publishing validation.

Add branding and review the preview

Add: Upload a logo and favicon if needed.

Set: Enter the brand name, heading, introduction, colours and suggested prompts. The brand name and heading are required.

Connect: Save the branding to the app draft.

Test: Review the preview and fix validation errors.

Expected: The review step shows the app type, address, access mode and branding. Publishing remains blocked while validation errors are present.

Publish and test the visitor page

Add: Review the saved app and select Publish Web.

Set: Keep the intended access mode in place when sharing its address.

Connect: Open the published address as a visitor. For login-required access, sign in with an allowed workspace account; for private-link access, use the issued link.

Test: Send a harmless text input that your workflow is designed to answer. Check the response and verify that users without the required access cannot run the protected app.

Expected: The app is marked published and returns the linked workflow’s text reply.

Common mistakes

• Sharing the address before testing the visitor view.
• Leaving a custom domain unverified.
• Changing a protected app to public without reviewing the confirmation.
• Assuming a dashboard, portal or custom app bypasses text-input and output limits.
• Expecting a settings edit to replace the published version without publishing again.

Troubleshooting

These are service error codes. A deployed interface may show a corresponding message.

Code	Cause / next check
invalid_field	Check the named field’s accepted format.
slug_already_used / address_already_used	Choose an unused address name or domain.
confirm_public_required / confirm_private_required	Review and confirm the requested access change.
custom_domain_used	The domain is already claimed by another app. Check ownership before choosing it.
publish_not_ready	Read the validation errors; set the brand name and heading, and verify any custom domain.
published_app_limit	Check the workspace’s published-app quota.
publish_quota_unavailable	Quota verification could not complete. Retry after the service recovers.
page_bundle_missing	Ask the administrator to deploy the published-page bundle.
publish_busy / publish_state_changed	Wait, reload the saved app settings and retry the review.
web_server_reload_failed	Ask the administrator to check the web server reload.
too_many_runs	The app is busy. Wait before retrying.
flow_not_ready	Check and test the linked workflow.
input_too_large	Shorten the visitor input.
flow_run_timeout / flow_run_failed	Check the linked workflow and its services before retrying.
insufficient_balance	The app is temporarily unavailable because the workflow cannot cover the run. Ask its owner to check the balance.

Related

Build and publish an AI chatbot for your website.

Publishing features and access modes. Model connections and variables. Explore AI Flowi Workflow.