Zendesk User Segments

In Guide, visibility is set on sections and inherited by the articles inside them, though an individual article can carry its own segment.

The behaviour when someone is excluded is important and under-explained. The article doesn't appear greyed out or behind a prompt. It does not exist. It is absent from browsing, absent from search, and a direct link produces a not-found or a sign-in page rather than an explanation.

That is the right default for security and a common source of confusion for admins, who see an article perfectly well from their own account and cannot understand why the customer says it is missing. Test signed out and test as a real customer account. Every time.

Segments also pair with a separate management permission that controls who can create and edit articles, which is a different axis entirely. Viewing and editing are configured separately, so check both when something looks wrong.

Segments built on tags are only as reliable as whatever writes the tags, and that's where these break in practice.

If a tag is applied manually, it will be applied inconsistently. Within a year you have vip, VIP and vip_customer, and your segment catches one of the three. Write tags from an integration or an automation, name them with a convention, and document what each one means somewhere an admin will find.

Audit annually. Users keep tags after they downgrade unless something removes them, so a churned enterprise customer can still be reading your enterprise-only documentation two years later. Nobody notices, because nothing errors.

Keep the total number small, too. Every segment is a rule someone has to understand later, and a help centre with fifteen of them has a permissions model nobody can hold in their head. Three or four well-chosen segments cover most businesses, and the temptation to add a fifth is usually a request that a single article should have handled differently.