Knowledge base and help center

Each brand owns a knowledge base. Workspace owners manage it from Knowledge base in the console: create a category, add a section, then write an article. Categories and sections stay hidden until they contain published articles.

Articles support Markdown, a search summary, and display order. Save draft keeps changes private. Preview saved draft shows the saved content to workspace owners. Publish article / Publish changes copies the current draft into the public version; Unpublish removes the public version while preserving the draft. Draft titles, bodies, summaries, section moves, order, and timestamps do not change the published article until publication. Editing category or section names/order applies immediately, as described in their editors.

Published articles are public. Requester portal sign-in rules protect ticket submission and conversations, independently of the knowledge base. All editor pages/actions require workspace ownership and validate the selected brand.

Addresses

Every brand's help center is on APP_URL, the one address Bouée runs at:

• / is where customers start. Home page on /instance/settings chooses what it shows: every team, as a list linking to each team's help center, or one brand's help center. With one team, "every team" is that team's help center.
• /?brand=<brand id> is a brand's help center; a workspace's first brand has the workspace's id. /articles/<id>, /categories/<id>, /sections/<id> and /search serve its published content, and every link names the brand, so saved links, forms and emails stay with it.
• /requests/new?brand=<id> chooses a form and submits a request, /requests/<token> opens a conversation, and /sign-in is customer sign-in; existing customer sessions continue to /requests.
• /login and /agent open agent sign-in, and /workspace/<id>/… is the console.

A brand can also give its knowledge base an address of its own. Reserving the slug alpha gives the brand alpha.bouee.dev (its knowledge base and its support@ address in one act), and a customer may point a hostname they own at that name by CNAME. There, the hostname says which brand it is:

• /, /articles/<id>, /categories/<id>, /sections/<id> and /search serve that brand's published content, with no ?brand= in their links, including for signed-in agents.

• Contact support, My requests and Customer sign in lead to APP_URL with ?brand=<id>.

• Every other path returns 404: src/proxy.ts decides it from the Host header alone.

• The former /hc, /hc/en-us, /customer, /<workspace>/hc/... and /<workspace>/portal/... routes are removed. They return 404; there are no compatibility redirects. Previously issued links using those paths must be replaced.

• Customer SSO has one redirect URI for every brand, APP_URL/sign-in/sso/callback; the sign-in's state cookie says which brand it is for. Register it at the identity provider before using SSO; see company sign-in.

See brand hostnames and custom domains for the CNAME target, the ownership TXT, reserved slugs, and operator-managed HTTPS routing.

Languages and publishing safety

English (en-us) is currently the only supported locale. Categories, sections, and articles have stable identifiers, with content in separate locale records. Language is internal data and is not part of current public URLs. Future translated routes can be introduced separately; current article IDs remain stable.

Public queries read only published snapshots and remain scoped to a brand and locale. Markdown is sanitized before HTML rendering. Optimistic revisions prevent stale edits from overwriting newer work; same-brand database constraints and serialized publication preserve article placement. Public search is limited to 120 characters and 50 results.

The additive 20260919090000_knowledge_base migration creates the knowledge-base and custom-domain tables and settings. It does not publish sample articles or modify tickets.