Preview & Publishing
Preview links
Section titled “Preview links”A preview link is your private, internal way to try the assistant exactly as it is configured right now.
URL shape: /chat/<projectId> (a long internal ID, not a friendly name).
What preview links are
Section titled “What preview links are”- Internal only. Opening a preview link requires being signed in as a member of the organisation with permission to read the assistant. A logged-out member of the public who receives the link cannot open it — they get a permission error. Treat preview links as internal QA tools, not something to hand to customers.
- Always the latest saved config. Preview serves the editable assistant configuration, not a published snapshot. Every setting you save is reflected immediately — this is the whole point of preview: test before you publish.
- Renders through the default preview device. The dashboard Preview button renders through your project’s default preview device, so you can see how your assistant appears on that device — including any custom HTML template — without publishing. If that device has a custom embed template enabled, Preview wraps the chat in it; otherwise it shows the plain chat UI. Preview traffic is not attributed to any device in the per-device analytics breakdown.
What preview links still do
Section titled “What preview links still do”- They still call the real AI providers. A preview conversation runs the same model, voice and avatar pipeline as production. That means preview sessions still consume budget and show up in your organisation’s cost tracking (Dashboard → Billing). Preview is free of audience, not free of cost — an avatar preview burns avatar minutes just like the real thing.
Preview requires a device
To use the dashboard Preview button, your project must have at least one device. The first device you create becomes the default preview device.
Publishing
Section titled “Publishing”Publishing is the step that makes an assistant reachable by the public.
What happens when you publish
Section titled “What happens when you publish”Publishing creates a snapshot — a frozen copy of the assistant’s persona, safety/RAG settings, interaction settings, actions, enabled flows, the compiled system prompt, and the current set of linked knowledge libraries. Each publish bumps a version number (v1, v2, …); the newest active snapshot is what the public sees.
The important consequence:
- Public links serve the snapshot, not your live edits. After you publish, you can keep editing the assistant safely — nobody sees those changes until you publish again (new version) or refresh the current snapshot in place.
- The first publish asks you to choose a slug — a short, URL-friendly name (3–80 characters, lowercase letters, numbers and hyphens). This becomes part of every public URL, so pick it deliberately; it is reused on every later publish.
What a published link is
Section titled “What a published link is”Once published, the assistant is served at friendly, public URLs built from your org slug, project slug and a device slug:
/chat/<orgSlug>/<projectSlug>/<deviceSlug>- Public. No login is required (unlike preview). Anyone with the link can open it — subject to the device’s own access controls (IP allow-list, LTI-only, HMAC signing).
- Attributed to a device. Because a published link always points at a device, its conversations feed the per-device analytics, device breakdown and the campaign meter.
- Stable. The URL does not change when you republish; only the underlying snapshot does.
Unpublishing
Section titled “Unpublishing”Unpublishing deactivates the snapshot so the public URLs stop serving, while keeping the slug and history so you can re-publish later.
Keeping published content current
Section titled “Keeping published content current”Remember the snapshot model: edits are invisible to the public until you re-publish (new version) or refresh the active snapshot. Build a habit of previewing, then publishing, so you always know exactly what the world is seeing.