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.
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.
Open Settings → Portal.
Under Access settings, find the Multiple Portals toggle.
Turn it on (requires the Scale plan or above).
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.
Once you have portals, you can control which portal(s) each piece of content appears in.
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.
When editing a changelog entry, use the portal selector in the top bar to assign it to specific portals.
In the docs editor, the portal selector in the header lets you assign an article to one or more portals.
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.
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.
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).
Open a changelog entry.
Click the Audience button in the toolbar.
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.
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.
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.
