Controlling access at the article level

Ref: C12 · Track: Knowledge Base Admin · Time to complete: ~5 min

Why this matters

Not every article should be visible to every visitor. Pricing tiers, partner-only content, internal-only runbooks, VIP documentation — the help center becomes a lot more useful when access is tuned. Access control is the feature.

The four visibility scopes

Each article (and each section) can be set to one of these:

Everybody

Anyone with the URL — signed in or not — can read the article. Public help center content.

Signed-in users

Only users who have an account and are logged into the help center. Often used for customer-only content.

Agents and admins

Internal. Never appears on the public help center regardless of URL. Good for ops runbooks, escalation scripts, or "for internal use" FAQs.

Custom — user segments

Restricted to one or more user segments (see C13). The most flexible scope: partners-only, VIP customers, enterprise-tier only, etc.

Where access is set

Access can be set at two levels, and the article inherits from the most specific:

1. Section-level — set the default for all articles inside a section.
2. Article-level — override the section default for a specific article.

Typical setup: set the section to "Signed-in users" and leave articles inheriting, then flip specific articles to "Everybody" if they're safe for public view.

Setting article-level access

1. Open the article.
2. In the right sidebar, find Visible to.
3. Choose one of the four scopes.
4. If Custom, pick the user segment(s).
5. Save.

If the article is published, visibility changes take effect immediately.

Who-can-manage (a separate setting)

Beyond who can read, there's who can edit. Zendesk calls this Managed by:

• Everyone in this team
• Managers and admins only
• Custom (per role)

This controls which of your internal staff can author, edit, review, or publish the article. Don't confuse this with visibility — managed-by is about staff access; visible-to is about reader access.

The matrix — permissions vs segments

You can combine: - Visible to: Custom segment "Partners" - Managed by: Managers and admins only

Result: only partners can read it, only admins can edit it. Useful for sensitive partner content you don't want the whole support team casually editing.

Gotchas

• Section-level access overrides inherit visibility. If you change a section from public → signed-in, all articles that were inheriting that setting also flip. Spot-check afterwards.
• Custom segments require users to be assigned. An empty segment = nobody sees the article, even if access is "Custom → Partners", if no user has the Partners segment yet.
• Search obeys access. A signed-out visitor searching won't see signed-in content — it doesn't appear in search results at all.
• Direct URLs still 401, not 404. A gated article returns an authentication prompt, not a missing-page error. Often fine, but worth knowing for link integrity checks.
• Internal articles and agents. "Agents and admins" visibility is often used for internal how-tos shared during ticket work. These don't leak externally.

A simple setup for a mid-size B2B

• Category "Public knowledge" → section defaults = Everybody
• Category "Customer knowledge" → section defaults = Signed-in users
• Category "Partner portal" → section defaults = Custom: Partners segment
• Category "Internal runbooks" → section defaults = Agents and admins

Override per-article where useful. This scales cleanly and is easy to audit.

Quick check — have you got this?

• You want an article visible to signed-in customers but not to anonymous visitors. Setting?
• You set a section to signed-in. Can an individual article still be public?
• What happens if the same user is in two user segments and the article requires only one?

Related articles

• C05 — The book — managing all your content
• C13 — User segments: partner-only or VIP-only content
• C20 — Global KB settings: require sign-in, unsafe content, GA