Writing and publishing articles
The Content list and the article editor: modes, the toolbar, AI drafting, the details rail, share links, slugs and publishing.
Knowledge → Content (/help-centre/content) is every article in the help
centre, and the editor behind it is where they are written. Both are
editor-level: any editor can write, publish and delete articles.
The Content list
The list is one locale's worth of articles at a time. Locale is not a filter over a multilingual list — it is the list's identity, which is why the locale control sits in the main bar rather than behind the disclosure.
The filter bar carries a debounced search over titles and text, then Locale, Collections and Owner as dropdowns, and a + Filters disclosure holding three chip groups:
| Group | Options |
|---|---|
| Visibility | Public · Hidden: staff only · Internal |
| State | Published · Draft · Archived |
| AI knowledge base | Out of date · Needs removing |
The disclosure counts what is applied inside it and opens itself whenever one of those filters is set, so a filter can never be on and invisible. Every filter lives in the page address, so a filtered list is a link.
The table's columns are Title (the only sortable one), Type, Help Center, Collections, Owner, Locale, State, AI-trained and Updated. Columns drop by available table width, narrowest and least-populated first; Title never yields. Sorting is a server round trip in every case — nothing reorders the fifty rows in hand and presents that as a corpus-wide sort.
Fifty rows a page. There are four different empty states, never one: no help centre at all, nothing imported yet, nothing in this locale, and nothing matching these filters.
Bulk actions
Ticking rows replaces the bar with one selection bar. It states the number of ticked rows on the left, with Clear beside the count, and four verbs on the right: Delete, Move, Remove … from AI and Train … with AI.
Each button states its own scope. An action that can only apply to some of the selection says so on its own label — Train 12 of 30 with AI — rather than a second bar with a second count. Every confirmation names what it will touch, and the selection survives paging.
Deleting an article is done here, not in the editor. It cannot be undone, deleting the last translation removes the article, and imported articles are refused with a suggestion to archive instead.
The editor
The editor has a title and a description at the top, then the body.
Three modes over one box
The body pane offers Write, Split and Preview. Split shows a live render beside what you are typing and is offered only where two columns fit; neither pane grows the page.
The preview always says which render it is showing
The server's stored render is the article. The client's render of unsaved text is an approximation of what the article will become. The pane names which one is on screen, in text rather than in a tooltip — and it refuses to approximate at all when it cannot confirm that your browser's formatting rules match the ones your help centre is on.
The toolbar, the slash menu and the shortcuts
Thirteen toolbar controls: bold, italic, strikethrough, inline code, heading 2, heading 3, bulleted list, numbered list, quote, code block, link, image and table.
Typing / on an otherwise empty line opens a block menu with ten entries —
the toolbar's set minus the inline emphasis, plus a divider. A slash mid-sentence
is a literal slash and opens nothing. The menu filters as you type, and matches
aliases as well as labels, so /ul finds Bulleted list.
Five keyboard shortcuts, on your platform's own modifier: B bold, I italic, E inline code, K link, X strikethrough.
You can paste or drag an image straight into the body to upload it.
A body you cannot edit gets none of this
An imported article, or one stored as HTML rather than as text you typed, opens as a read-only source pane with the reason stated: the body is edited where it is published from. No toolbar, no slash menu, no shortcuts, no upload — absent rather than disabled. The title, description and everything on the rail still save.
The two AI actions
One button, Ask Auralis to draft, which does one of two things depending on what is selected in the body when you press it:
- Nothing selected — drafting. You describe what the article should cover, and the result is inserted at the caret.
- A passage selected — improving. The dialog becomes Improve with Auralis, asks how it should change, shows you the passage it is working on, and replaces that range.
Both take a free-text prompt and see the article's title, description and collection — never its body beyond the passage you selected. There is no diff or accept step: the text lands in your working copy, and nothing is saved. The dialog says so, and adds that you should review it before you publish.
Treat both as a first draft. You are the one who knows whether the product actually behaves the way the paragraph claims.
The button is absent, not disabled, where AI drafting is unavailable — it needs a model provider configured for the workspace.
Saving and publishing
The sticky header carries a breadcrumb, the locale, View (the live article, where there is one), the Details toggle, and Save. Publish appears only when the article is not already published; it is the ordinary save with the editorial state set to published, so there is no separate publishing permission.
Under the bar, a status line: Saving…, Saved. This is what visitors get., Unsaved changes., or Fix the highlighted fields to save. — with Discard changes beside it.
Drafts autosave their body after a short pause. Published articles never autosave.
Unsaved work is kept, and never silently applied
A copy of unsaved changes is held in your browser for two weeks. Coming back, you are offered Restore them or Discard them, with a summary of how they differ from the saved article — an offer, never an automatic apply. Navigating away with unsaved changes asks first, and says plainly that leaving does not save any of it.
The details rail
To the right of the editor, under Settings, in order:
| Field | Notes |
|---|---|
| Slug | The last part of the address. See below. |
| State | Published, Draft or Archived. |
| Visibility | Public, Hidden: staff only, or Internal. |
| Collection | Where it sits. Without one it is reachable by address and search, but is in no menu. |
| Owner | A member, or nobody. |
| AI knowledge base | The include toggle. See Handing articles to the AI. |
| Review | Open preview and Share a draft…. |
| Language | The locale switcher, and Add language for a new translation. |
Where an article is published but its visibility would keep it off the live site, the rail says so at the top in bold, with a one-press Also make public. Where it is live, it says that instead.
Visibility and collection belong to the article, not the translation, so changing either moves every language at once. The rail warns you when there is more than one.
There is no delete control in the editor. Deletion is a bulk action on the Content list.
Preview and share links
Open preview renders the stored version, whatever its state, with the visitor's typography and contents list. It is not what visitors see unless the article is published and public, and it says so. Unsaved changes are not in it — save first if the reviewer should see them.
Share a draft… mints an expiring link that anyone can open without an account. They get that one translation and nothing else in the help centre.
Choose how long it lasts: 1 day, 7 days or 30 days. Seven is the default.
Copy the link there and then. Only a one-way fingerprint of it is stored, so it is never shown again.
Revoke it from the same dialog when the review is done.
A draft can hold at most five live links at once; over the cap you are told to
revoke one to make room. Expired and revoked links stay on the record as a count
and open nothing. The preview responses are served no-store and marked
noindex, so a shared draft does not end up in a cache or a search engine.
This is how you get a colleague or a subject-matter expert to check an article before it is public, without publishing it first and hoping nobody finds it.
Slugs, and why old ones keep working
The slug is the article's address on the public site. A published article's URL is built from the locale, the path of collections it sits in, and the slug.
A slug is generated from the title the first time the article is created, and it does not change when you later rename the article. That is deliberate: a URL that silently changed every time somebody tidied up a heading would break every link anybody had ever shared.
You can change a slug deliberately. When you do, the old one is kept and permanently redirects to the new one — a real 301, recorded in the help centre's slug history. Nothing that was linked stops working. The rail tells you this on the field, and tells you in advance if what you typed will be stored differently once normalised, or refused because none of it can be used in an address.
A slug already in use in the same locale is refused rather than silently suffixed.
There is a matching guarantee on the reading side. An article is resolved by its slug alone, so a visitor arriving with an out-of-date collection path in the URL is redirected to the correct address rather than getting a 404. Moving an article between collections therefore never produces a broken link.
Deleting a translation takes its slug-history redirects with it.
Editorial state and visibility are separate
Two independent facts, and both have to line up for a visitor to reach an article.
| State | What it means |
|---|---|
| Published | Live, if its visibility and every collection above it allow it. |
| Draft | Not served to visitors, whatever its visibility says. |
| Archived | Kept, not served. Nothing has been deleted. |
| Visibility | What it means |
|---|---|
| Public | Anyone can read it on the help centre. |
| Hidden: staff only | The source restricted this to signed-in users. The help centre has no visitor sign-in, so it is hidden from every visitor and reachable only by staff here. |
| Internal | Staff only. Visitors get the same page as content that does not exist. |
So an article can be published and internal at the same time — a finished, in-use article that is simply not for customers. And a row reading Published on a site that does not have it is telling you the other half is wrong, usually a collection above it.
Imported articles
An import keeps the provider's original bytes and separately stores a sanitised version that the public site serves. The served version is not byte-for-byte identical, because third-party markup passes through a strict allow-list before it is published on your domain.
What was removed is recorded and shown to you rather than dropped silently, on the article itself: what the sanitiser removed, which links could not be pointed here, and which images and files were not copied. Because the original is kept, the published version can always be re-derived — and saving a new body clears those reports and re-derives the render.