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. When you upload a logo for a portal, a crop dialog lets you drag to reposition and zoom before saving it.

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. As with sub-portal logos, you can crop it before saving.

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. When you publish or send an update for a changelog assigned to a named portal, the email broadcast defaults to that portal's name and logo instead of the workspace's. See Broadcasts for details.

Docs articles

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

Sending updates from a portal

When you send an email update (see Broadcasts) for a changelog, project, or issue assigned to a specific portal, the sender name in the send-update modal defaults to that portal's name instead of your workspace name. You can still edit it before sending.

API support

The public API v2 supports portals directly:

• GET /portal/instances lists the workspace's portals (id, slug, name, whether it is the default portal, whether it shows in the portal selector, and logo URL). The Main (Root) portal is implicit and is represented elsewhere as a null portal_instance_id.

• Docs groups (POST /docs/groups, PATCH /docs/groups/:id), docs articles (POST /docs, PATCH /docs/:id), and changelogs (POST /changelogs, PUT /changelogs) accept an optional portal_instance_id field to assign the item to a portal.

• List endpoints for docs groups, docs articles, and changelogs accept a portal_instance_id filter. Pass __main__ to filter to the Main (Root) portal, or omit it to return items across all portals.

• A new docs article created without a portal_instance_id inherits its group's portal. Pass null explicitly to force the Main (Root) portal instead.

• Passing a portal id that does not belong to the workspace returns a 404.

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.

Search on a named portal follows the same scoping: a search only returns issues and projects that are assigned to that portal (or to "Visible for all"), so visitors never see results from a different sub-portal. See Publish your roadmap for how portal search handles issue descriptions.

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.

Productlane Agent docs indexing

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

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