Skip to Main Content
Portal Access and Display

Publish a Roadmap Without Publishing Everything.

Decide what visitors can browse, whether they must sign in, which interactions are enabled, which fields appear, and how the roadmap and changelog are presented.

Example public-board policy

Browsing
Public by link
Interaction
Login required
New feedback
Admin approval
Visible work
Selected public labels

How much control do I have over a public Feedvote board?

You can let anyone browse the board or require login for participation; disable voting, comments, and posting with read-only mode; stop only new submissions; moderate new feedback before it appears; filter public items by label; choose displayed metadata; and control portal navigation and changelog visibility.

What you control

Controls available in Feedvote

These are working Feedvote controls, not a simplified marketing concept.

01Public browsing
Share a board by link while keeping participation rules separate from what visitors are allowed to read.
02Read-only mode
Disable voting, commenting, and posting when the portal should communicate progress without collecting input.
03Submission controls
Pause new feedback while leaving existing voting and discussion available, or require an account before any interaction.
04Moderation and approval
Keep new submissions hidden until an admin reviews them, so the public board stays intentional and useful.
05Public-board label filter
Choose which labeled records public visitors may browse while the team retains access to the full internal board.
06Displayed fields
Show or hide category, status, priority, Linear project, initiative, owner, and cover-image information.
07Navigation and changelog
Choose which portal sections appear, add custom navigation links, and set how the changelog is exposed.
08Brand and board structure
Configure the board name, subdomain, visual identity, categories, and the roadmap statuses customers see.

Workflow

Separate Visibility, Participation, and Presentation

Feedvote does not force every public board into the same openness model. Configure each layer according to the audience and the stage of your program.

  1. 01

    Choose Who Can Browse

    Make the board public by link or use customer-specific access for controlled audiences.

  2. 02

    Choose How People Participate

    Allow feedback, votes, and comments; require login; or switch the experience to read-only.

  3. 03

    Choose What Becomes Visible

    Moderate submissions and use labels to define the work anonymous visitors can browse.

  4. 04

    Choose What the Interface Explains

    Show only the metadata, navigation, statuses, and updates that help this audience understand the roadmap.

Common questions

Portal Access and Display FAQ

Clear answers about setup, visibility, and what customers can see after you publish.

Can a public roadmap be read-only?

Yes. Read-only mode disables voting, comments, and new posts while keeping the published roadmap available to browse.

Can people browse without an account but sign in to interact?

Yes. Public browsing and interaction requirements are separate controls, so you can keep the roadmap open while requiring login before posting, voting, or commenting.

Can we approve feedback before it becomes public?

Yes. Enable admin approval and new feedback remains hidden until your team reviews it.

Can we hide internal fields from customers?

Yes. Choose whether the public interface shows category, status, priority, Linear project, initiative, owner, and cover-image details.

Make your Linear roadmap customer-ready.

Choose what to publish, control who can see it, and give customers one clear roadmap.