A customer can read an article only when it is published, its own visibility is Portal, every category above it is Portal, and their company is on its audience.
Fail any one of those and the article is invisible to that customer — not locked, not greyed out, genuinely absent from browse, absent from search, and its direct URL returns "not found".
Your own team is not affected by any of this. Members see everything published in the Library, internal and customer-facing alike. These controls exist to govern the customer side only.
Set in the editor's Audience panel, under Visibility:
New articles default to Portal (customers).
When you choose Internal, a hint appears: "Internal articles never appear on your customer portal." In the Library, internal articles carry an Internal badge so your team can tell at a glance whether a customer is also reading it.
Changing this takes effect on the customer's very next page load. There is no republish step.
This is the newest control and the one worth understanding properly, because it is the one that acts at a distance.
A category has its own audience, set in the category dialog under Audience:
Setting a category to Internal hides everything nested underneath it from the customer portal — every subcategory, every article, however deep, including articles added later. The hint in the dialog states it directly:
Internal hides this category — and everything nested under it — from the customer portal, whatever the individual articles say. Articles keep their own audience setting.
That last sentence is the important one, and it leads to the two properties below.
Marking a category Internal does not rewrite the articles inside it. Their own visibility setting is left exactly as it was. The hiding is worked out fresh every time someone reads, by walking up the category tree.
The practical consequence is that the change is completely reversible:
Step 3 is what a cascade would get wrong. If marking the section Internal had stamped "internal" onto every article, turning it back on would have published articles you had deliberately kept private. Because nothing was written down, there is nothing to get wrong.
When a category sits under an Internal ancestor, its own Audience control stays editable and keeps showing that category's own setting. The inherited restriction is explained beside it rather than applied to it, because the two are genuinely separate facts: what this category is set to, and what an ancestor is currently doing to it.
The hint names the ancestor, then tells you what it means for this category. If this category's own setting is already Portal, there is an action to take:
Runbooks is Internal, so this category and everything under it is hidden from customers right now. Re-open Runbooks to make this one visible — your setting here is already Portal.
If the category is Internal in its own right as well, re-opening the ancestor would not be enough, and the hint says so instead of promising otherwise:
Runbooks is Internal, so this category and everything under it is hidden from customers right now. This category is also Internal in its own right, so it stays hidden even if Runbooks is re-opened.
This updates live as you edit. Changing the Parent category in the dialog to something Internal makes the notice appear before you save, so you can see what filing it there is about to mean.
In the Manage category tree, an Internal badge appears on every category that is effectively internal — including ones that are internal only by inheritance. Hovering tells you which kind:
The badge deliberately appears on inherited ones too. A badge that showed only on the parent would leave every child looking public when it is not.
The Visibility column on the Manage article table shows what each article is set to, not what a customer would experience. An article can read portal there and still be hidden by a category above it — that column is an editing surface, so it deliberately shows the stored value.
The surfaces that tell you the effective answer are the Internal badge on the category tree, the badges in the article library and reader, and the editor, which names the category responsible:
Hidden from customers: the category Runbooks is Internal. This article's own audience is unchanged and applies again when that category is available to customers.
The editor's own Audience controls keep showing and saving the article's own setting, for the same reason the category dialog does — the clamp is never written into the article.
Portal-visible articles can be narrowed to specific customer companies. This lives in the same Audience rail panel, under Companies, with an Edit button.
In the Article audience dialog:
The summary in the rail reads All companies, 1 company, or companies.
You can set the company audience while the article is still Internal. That is deliberate: it lets you narrow the audience before exposing the article, rather than publishing to everyone and restricting afterwards. The rail explains this with the hint "Audience applies only to portal-visible articles — set it now and it takes effect when visibility switches to portal."
The gates are evaluated in order, and all must pass:
| # | Gate | Where you set it | Fails when |
|---|---|---|---|
| 0 | State | Publish button | Article is a draft or archived |
| 1 | Visibility | Editor → Audience → Visibility | Set to Internal |
| 2 | Category audience | Category dialog → Audience | Any ancestor category is Internal |
| 3 | Companies | Editor → Audience → Companies | The reader's company is not on the list |
An uncategorized article skips gate 2 entirely — it has no ancestors, so nothing clamps it and its own visibility decides.
Work down this list in order.
published. A draft or archived article is invisible to customers regardless of everything else.Deleting an Internal category preserves its restriction. Normally the audience is derived and never written down. Deleting a category is the one exception, because the category is disappearing and so is the rule it was enforcing — there is no way to "put it back".
So deleting a category never makes its contents customer-visible. Where the restriction would otherwise be lost, DevStride writes Internal down on what survives: the articles that become Uncategorized, and the child categories that move up a level. Where it would not be lost — because a surviving parent is still Internal and still hides them — nothing is written, and those categories keep their own setting so re-opening that parent later restores them properly.
Either way the outcome is the same from a reader's point of view: nothing that was hidden becomes visible. Anything written down is visible in the UI and can be widened again deliberately. Deleting a Portal category changes nothing at all.
Moving things does change who can read them. Dragging a category out from under an Internal parent, or dragging an article from an Internal category into a customer-facing one, makes that content readable by customers straight away. This is correct — you moved it — and it is fully reversible by moving it back. But DevStride does not currently warn you at the moment of the drop, so be deliberate when reorganizing a tree that mixes internal and customer-facing sections.
Organizing with Categories
Build the category tree your readers navigate — creating, nesting, reordering, filing articles, and what happens when you delete a category.
The Article Lifecycle and URLs
Draft, published, and archived — what each state means, how to move between them, and how article URLs are created and changed.