Multiple Portals

With Multiple Portals you can serve different audiences from a single Productlane workspace. Each portal is a named view of your content - you decide which projects, issues, changelogs, and docs articles appear in each one.

When to use multiple portals

Multiple portals are useful when you need to show different content to different groups of people. Common examples:

• Customer tiers - show enterprise customers a different roadmap than free-tier users.

• Product lines - maintain separate feedback portals for each product.

• Internal vs. external - keep an internal portal for your team and a public one for customers.

Enable multiple portals

1. Open Settings → Portal.

2. Under Access settings, find the Multiple Portals toggle.

3. Turn it on (requires the Scale plan or above).

4. Create your first portal by entering a name and clicking Create.

You can rename or delete portals at any time from the same settings page.

The Main portal

The Main portal is the default portal that maps directly to your workspace. It is always listed first on the Settings → Portal page and cannot be deleted or given a URL slug.

You can edit the Main portal's name and logo by hovering over its row and clicking the edit (pen) icon. The dialog lets you:

• Rename your workspace (the name shown on the Main portal and across the dashboard).

• Upload or replace the workspace logo used on the Main portal.

Because the Main portal represents the workspace itself, changes here update the workspace name and logo globally - not just on the portal.

Assign content to portals

Once you have portals, you can control which portal(s) each piece of content appears in.

Projects and issues

On the roadmap list, each item has a portal selector pill. Click it to choose:

• Visible for all - the item appears on every portal and the main view.

• Hidden - the item is hidden from all portals.

• Specific portals - select one or more portals where the item should appear.

You can also change portal assignments from a project or issue detail page.

Changelogs

When editing a changelog entry, use the portal selector in the top bar to assign it to specific portals.

Docs articles

In the docs editor, the portal selector in the header lets you assign an article to one or more portals.

Portal navigation

When multiple portals are enabled, a tab bar appears in the sidebar of the Roadmap, Changelog, and Docs sections. Use it to filter the list by portal or to view hidden items.

Keyboard shortcuts 1 through 9 switch between tabs quickly.

Portal selector on the public portal

Visitors to your public portal see a portal selector dropdown in the header (next to your workspace name). They can switch between portals to see the content relevant to them. If no portal is selected, all public content is shown.

The portal context is passed as a ?portal=<id> query parameter, so the selected portal persists across page navigation.

Widget and sub-portal content

The Productlane widget is tied to your workspace as a whole, not to any individual sub-portal. This means:

• The widget always loads changelog entries, docs articles, and roadmap content from the Main portal by default, regardless of which sub-portal URL it is embedded on.

• Content that is assigned only to a specific sub-portal (and not to "Visible for all") will not automatically appear in the widget just because the widget is placed on that sub-portal's site.

Why this happens

The widget is initialized with a single workspace-level widget key (widgetKey). It has no built-in way to detect which sub-portal it is running on, so it falls back to the Main portal's content set.

Workaround

If you need the widget to surface content specific to a sub-portal, make sure all content you want widget visitors to see is also assigned to "Visible for all" (in addition to the specific sub-portal). That way it appears in both the sub-portal view and the widget.

Note: Support for scoping the widget to a specific sub-portal is being investigated. If you are affected, contact support so your case can be tracked.

Changelog audience restriction

Individual changelog entries can be restricted to specific email domains, independent of portal assignments. This is useful when you want to share a changelog with only certain customers (for example, beta participants).

Per-entry restriction

1. Open a changelog entry.

2. Click the Audience button in the toolbar.

3. Add one or more email domains (e.g. acme.com).

Only portal visitors signed in with a matching email domain can view the entry. Anonymous visitors are redirected to the portal login page. Visitors with a non-matching domain see a 404.

Restricted changelogs are automatically hidden from:

• The public changelog listing for non-matching visitors.

• The RSS feed for non-matching or anonymous visitors.

• The widget (since the widget cannot verify viewer identity).

• The public API when called without authentication.

To remove the restriction, clear all domains or click Visible to everyone.

Workspace-level restriction

You can also restrict the entire changelog section to specific email domains from Settings → Changelog. Toggle Restrict to specific domains on and enter a comma-separated list of domains. This requires the Scale plan.

API support

The changelog API (POST /changelogs, PUT /changelogs) accepts an optional allowedEmailDomains field - an array of bare domain strings (e.g. ["acme.com", "example.com"]). The GET endpoints include allowedEmailDomains in the response. Unauthenticated API requests never return domain-restricted changelogs.

Known limitations (beta)

Multiple Portals is currently in beta. The following limitations apply while the feature matures.

Public API v2 and sub-portal groups

Articles created via the Public API v2 inside a sub-portal docs group are stored correctly but do not appear in the sub-portal UI. Portal assignment for API-created docs articles is not yet fully integrated with the multi-portal pipeline.

Workaround: Create and assign docs articles to sub-portals from the Productlane editor instead of the API until this limitation is resolved.

AI Agent docs indexing

In multi-portal workspaces, published docs articles may not be indexed by the AI Agent due to a docs-sync gap in the multi-portal beta. This means the AI Agent may not be able to answer questions that are covered by your help center articles.

Workaround: If you notice the AI Agent is not finding answers from your docs, contact Productlane support to request a manual reindex of your workspace. After the reindex, the AI Agent will pick up all published articles.