Knowledge Base — Portals

Path: Centers → Products → Knowledge Base → Portals · URL: /knowledge-base?tab=portals

What this page does

A portal is an audience-specific view of your knowledge base. Most teams have a handful — Vendor, Internal, Guest, Owner Partners, etc. Each portal has its own slug, its own access level, its own default language, and its own enabled state.

The portal is what determines:

• Which articles appear (each article is tagged with the portals it's published to).
• Who can read them (public, public-no-index, or authenticated only).
• What URL they live at (<your-domain>/<portal-slug>).

Common portal patterns

Pattern	Portals you'd create	Why
Single audience	One portal: Help.	Simple. Most companies starting out.
Customer + internal split	Help (public), Internal (auth only).	Customers see customer-facing docs; staff see ops docs.
Per-persona	Renters, Owners, Vendors, Internal.	Each persona gets the docs they need without seeing irrelevant ones.
Per-region or per-language	Help (EN), Help (ES), Help (DE).	Strong localization needs; clearer than one portal with translations.
Public + private	Help (public), Partner (auth only).	You have a partner portal with proprietary integration docs.

Access levels — pick the right one

Access Level	Who can see	When to use
Public (indexed)	Anyone, including search engines	Customer-facing help, marketing collateral. Best SEO.
Public (no-index)	Anyone with the URL	Soft-launch portals, beta docs. Search engines told to skip.
Authenticated only	Signed-in users only	Internal docs, partner docs, customer-account docs.

Steps — viewing portals

1. Click the Portals tab.

You'll see one row per portal, with each row showing the portal name, slug, access level badge, and default language:

The toggle on the right of each row enables / disables that portal for visitors. A disabled portal still exists; visitors just see a 404 if they try to reach it.

Creating or editing a portal

1. Click New Portal (top right) to create a new one, or the pencil / edit icon on an existing row.

A modal opens with the portal's settings:

2. Fill in the fields.

• Name — what your audience sees in the portal header (e.g., Vendor).
• Slug — URL slug (e.g., vendor produces https://<your-domain>/vendor). Must be lowercase, no spaces.
• Access Level — pick one (see table above).
• Default Language — which language to serve when none is specified by the visitor.
• SEO crawlable — secondary toggle that interacts with Access Level. Public (no-index) + SEO crawlable off is the strongest "don't index this" signal.
• Supported Languages — multi-select: EN, ES, FR, DE, PT, NL, IT, PL, SV, DA, NO, FI. Articles can be authored in any of these; visitors switch via the language picker on the portal.
• Description — short audience description. Shown in admin tools, not on the public portal.
• Enabled (visible to visitors) — master on / off for the portal.

3. Click Save Changes.

Newly-created portals start empty. Authors need to publish articles to the portal — typically via the article editor's "Portals" multi-select.

Localization (Supported Languages)

Wazzi's KB supports authoring the same article in multiple languages. The Supported Languages multi-select tells the portal which languages it should offer to visitors. The article editor lets authors translate each piece of content per supported language.

If a visitor's browser is set to French and your portal supports EN, FR, they get the French version. If they're set to a language you don't support, they fall back to the Default Language.

Troubleshooting

• Visitors see 404 at my portal URL. Either the portal is disabled, the slug is wrong, or your custom domain isn't yet live (see Knowledge Base — Domains).
• Authenticated portal isn't prompting for sign-in. Visitors need to sign in via your org's identity provider — verify SSO is configured. For Wazzi-only auth, they can sign up at the portal's /login route.
• Articles I expect to see don't appear. Open the article in the editor and check its Portals field — articles are explicitly published to portals.
• Search results show articles from the wrong portal. The portal-scoped search index typically refreshes within a few minutes of an article-portal binding change. Trigger a manual reindex from the article editor if it's urgent.

Best practices

• Start with one portal, split when there's a clear reason. Splitting too early creates "lonely portal" syndrome where each portal has 3 articles.
• Use Public (no-index) for staging-style portals. Lets you share a URL with reviewers without polluting search results.
• Keep slugs short and stable. Once a portal is live and customers have bookmarks, changing the slug breaks links.
• Authenticated portals deserve a clear sign-in CTA. Don't make visitors guess — surface the sign-in button prominently.

Frequently asked questions

Can a portal require auth from a specific group only?
Not directly — Authenticated only means "any signed-in Wazzi user in your org." For finer access control, use a public portal and gate sensitive articles via portal membership.

Can I delete a portal?
Yes — but only if it has no articles published to it. Otherwise, unpublish all articles from the portal first, then delete it.

What happens to articles when a portal is deleted?
Articles aren't deleted — only their binding to the portal is. They remain available in any other portal they're published to.

How does the Knowledge Base MCP connector see portals?
The connector respects portal access levels. Public portals' content is searchable by any AI agent with KB read perms; authenticated-only portals' content is only searchable by agents acting on behalf of signed-in users. See The Knowledge Base Connector.

What's next

• Brand the portals: Knowledge Base — Theme.
• Wire up your URL: Knowledge Base — Domains.
• Restrict who in your org can edit portal settings: Managing Permissions → Centers → Knowledge Base.