Publishing knowledge articles to a portal

What it does

Published knowledge articles can be surfaced to customers on a Power Pages site, where visibility is controlled by content access levels layered on top of web roles. Separately, Customer Service can be told the URL pattern of an external portal so agents can copy a customer-facing link straight from the article.

Key facts

Content access levels are a second permission layer, independent of web roles. An article can be tagged with one or more levels; a contact sees it only if they hold a matching level.
Three levels ship by default: Default, Registered Users and Premium Users. Default is associated with the Anonymous Users and Authenticated Users web roles.
The feature is off until you set the site setting KnowledgeManagement/ContentAccessLevel/Enabled to true. Its default value is false.
Contacts inherit content access levels from direct assignment, from a parent contact, from an account, or from a web role.
Navigation and search results on the site both respect content access levels, and they work alongside faceted search conditions.
A user hitting an article they lack the level for gets an "Article Unavailable" message rather than a 404.
Creating a new version or a translation of an article automatically copies across the associated products and content access levels.
To manage levels from the Customer Service Hub, the Portal Knowledge Article for Interactive experience form has to be added to the Knowledge Article table.
On the Customer Service side, Copilot Service admin center > Knowledge > Portals > Manage carries a Use an external portal toggle and a URL pattern of the form https://<portal-url>/kb/{kbnum}, where {kbnum} is replaced with the article's public number.
The same Portals section has Sync attachments to portal, which controls whether knowledge article attachments are made available on the site.
Publishing to a non-Power Pages portal is not a built-in capability. Microsoft's guidance is that a customiser writes a plug-in to pick up published articles, post them, and report views back.

When to use / skip

If the client wants customer self-service against the same content their agents use, this is the route, and it is a good one — one article, two audiences, one publish action. The alternative, maintaining a separate public KB, means the two diverge within a quarter.

Content access levels specifically are for tiered audiences: public articles anyone can read, deeper technical content for registered customers, premium content for a support contract tier. If everything on the portal is public to everyone, leave the site setting off and save yourself the complexity. Turning it on means every article now needs a level assigned, and articles created without one behave in ways the content team will not predict.

Be realistic about scope. A Power Pages site is a separate product, separate licensing, separate design and testing effort. It routinely gets treated as a small add-on to a Customer Service project and it is not. If the client just wants agents to be able to send a link to an existing corporate site, the external portal URL pattern gives you that for almost nothing — configure the pattern and stop there.

Configuration decisions

Power Pages site versus an existing external site. The URL pattern setting covers the second case cheaply; only build a site if there is a real self-service ambition.
Whether content access levels are enabled at all, and if so what the tiers are and how they map to the commercial model.
How contacts acquire their levels — per contact, via account, or via web role. Account-level inheritance is usually right for B2B and per-contact is usually wrong at scale.
Whether attachments sync to the portal, and what the review process is for what gets attached to a customer-facing article.
Whether the internal and external versions of an article are the same record with access control, or genuinely separate articles. Both are defensible; mixing them is not.
Who signs off that an article is fit for customers, and whether that is a separate approval step from internal publishing.

Gotchas

The site setting is off by default. Assign content access levels without enabling it and nothing filters — every article shows to everyone, which is the failure mode you least want on a public site.
Articles get the Default access level when created. On an enabled site, that means new articles are public unless someone changes it.
New versions and translations copy the access levels forward. Useful, but it means a version created from a public article is public too, including a draft rewrite that gets published in a hurry.
Publishing an article publishes it everywhere the portal is configured to show it. There is no separate "publish internally" and "publish externally" action on the standard publish dialog — the split is done with access levels, not with publish state.
The Portal Knowledge Article for Interactive experience form has to be added manually, so knowledge managers often cannot see or set access levels from the app they actually work in.
The {kbnum} pattern uses the article public number, which is environment-specific. A sandbox portal pointed at production numbers will 404 in confusing ways.
Attachment sync makes attachments customer-visible. Internal spreadsheets attached to an article for agent reference become downloadable.

Consultant notes

Separate the Power Pages workstream in the plan and the budget. Treating it as a Customer Service configuration task is the most common way these projects overrun.
Demo the "Article Unavailable" experience to the client. Their content team needs to see what a wrongly tagged article looks like to a customer.
Before go-live, walk the portal as an anonymous user and as each tier. Do it after content migration, not before — the failure is always in the tagging, not the configuration.
Push for an explicit customer-facing review step. Internal-tone content published externally is the risk everyone underestimates.
Check the attachment sync setting against a sample of real articles. Ask what is attached today, not what should be.

Worth another look if the client adds a support tier, or if the portal moves off Power Pages.