The Feature Requests portal is a public page where your users can vote on feature requests, suggest new ones, leave comments, and see where each request stands. It gives your product team a direct signal of user demand — no surveys or manual aggregation required.
Key Features
- Voting — Users upvote the feature requests they care about. Votes are a first-class signal: sort by most votes to see what your users want most.
- Suggestions — Users can submit new feature requests with a title and description directly from the portal.
- Comments and replies — Threaded discussions on each request. Your team can respond and users can reply.
- Tag filtering — Assign tags to feature requests in the dashboard. Users can filter the portal by tag to find relevant requests.
- Status tracking — Requests move through a visible lifecycle so users know what's being worked on.
- Admin responses — Attach a public-facing response to any request to communicate decisions or progress.
- Merge duplicates — Combine duplicate requests so votes are consolidated onto the canonical version.
Accessing the Portal
Every project has a dedicated portal URL based on its project key. You can share the direct link, embed it as an iframe, or pass an authentication token for verified user access.
Find your project key in the SeggWat dashboard under Settings > General.
Use ?embed=true when embedding the portal in an iframe on your own site. It removes the outer page chrome and adjusts spacing for embedded layouts.
Feature Request Lifecycle
Feature requests follow a defined status progression. Statuses are visible to users on the portal so they always know where a request stands.
| Status | Visible to all users | Meaning |
|---|---|---|
| Pending | No (submitter only) | Newly suggested, awaiting team review. Only shown to the person who submitted it. |
| Open | Yes | Accepted and open for votes and discussion |
| Planned | Yes | Confirmed for a future release |
| Started | Yes | Actively being worked on |
| Completed | Yes | Shipped |
| Declined | Yes | Will not be built. Consider adding an admin response explaining why. |
| Duplicate | Yes | Merged into another request. Votes and comments are consolidated on the canonical version. |
Whether new suggestions go directly to Open or start as Pending is controlled by the Auto-Approve setting in your portal configuration. See Portal Customization for details.
Typical Flows
Managing Feature Requests in the Dashboard
Navigate to Feature Requests in your project sidebar to see all requests.
Filtering and Search
Use the filter bar at the top of the list to narrow down requests by:
- Status — Open, Planned, Started, Completed, Declined, or Pending
- Tag — Any tag assigned to feature requests in the dashboard
- Search — Full-text search across request titles and descriptions
Updating a Feature Request
Open any request to:
- Change the status — Use the status dropdown to move the request along its lifecycle
- Add an admin response — Write a public-facing message that appears on the portal below the request description. Use this to explain decisions, share timelines, or acknowledge the request
- Add or remove tags — Keep your list organized and make portal filtering useful
- Edit the title or description — Correct typos or clarify the request without losing its vote history
Merging Duplicate Requests
When users suggest the same thing independently, merge the duplicate into the request you want to keep so votes and discussion land in one place:
Select the duplicate
In the Ideas list, open the request that should go away.
Set its status to Duplicate
Pick Duplicate from the status dropdown. A dialog asks which request to merge it into.
Pick the request to keep
Search your project's requests and select the canonical one. Requests that were themselves merged away can't be chosen.
Merge
Votes move to the canonical request (someone who backed both counts once), and the comment thread moves with them. The duplicate stays visible on the portal as Duplicate with a "Merged into" note pointing at the request you kept.
Creating GitHub Issues from Feature Requests
If you have the GitHub integration set up, you can push requests directly to your repository:
- Open any feature request in the dashboard
- Click Create GitHub Issue
- The issue is created with the request title, description, vote count, tags, and a link back to SeggWat
When the GitHub issue is closed, the request status automatically updates to Completed. When reopened, it returns to Started. See GitHub Integration for setup instructions.
Custom Portal Branding
Customize your portal's title, welcome message, accent color, logo, and background color from Settings > Feature Portal in your project. See Portal Customization for all available options.
Authentication
The portal page is always publicly viewable — anyone with the link can browse requests, comments, and statuses. Who can act (vote, suggest, comment) is set per project under Settings > Public Board > Public visitor voting:
| Policy | Who can act |
|---|---|
| Anonymous allowed (default) | Any visitor — a browser identifier is enough, no sign-in required |
| Require email verification | Visitors confirm their email with a one-time code first (see below) |
| Disabled | No public actions; only token-authenticated visitors can act |
A visitor arriving with a signed authentication token always bypasses these gates and acts with a verified identity. See End-User Authentication for step-by-step JWT setup in Node.js, Python, PHP, and Go.
Email Verification (No Integration Required)
When the policy requires verification — or when a visitor who doesn't use your app's sign-in wants a verified identity — the board offers a built-in, passwordless flow: the visitor enters their email, receives a 6-digit code, and enters it to confirm. Nothing to set up on your side; they only need access to their inbox. Verified visitors stay signed in on that browser for about 30 days.
My Activity
Once a visitor is identified — by a signed token or by verifying their email — they get a personal My activity page at /p/YOUR_PROJECT_KEY/me showing:
- My feature requests — everything they've suggested, with live status
- Following — requests they've voted on
- My feedback — feedback they sent through the widget, with team replies
Anonymous visitors who open /me are prompted to verify their email to unlock it.
Browser Agent Tools (WebMCP)
Some browsers can now let an AI assistant act on the page a visitor is looking at, through the WebMCP proposal. Your board publishes a small set of tools to that assistant, so a visitor browsing with an agent can ask it to "find whether anyone has already asked for dark mode, and upvote it if so" instead of scrolling and clicking.
The tools cover the board itself: read the board's context, search and read ideas, vote and unvote, suggest an idea, comment on one, read the changelog, and move the visitor to another board page.
Two things make this safe to leave on:
- It's the visitor's own identity, not a key. Every tool call goes through the same public API the board's own buttons call, same-origin, with the visitor's own credential — their session, signed token, or browser identifier. An agent can do exactly what the person at the keyboard could do by clicking, and nothing more.
- Your policies still apply. The voting and submission policies above gate agent calls exactly as they gate clicks. On a board that requires email verification, an agent's vote is rejected until the visitor verifies through the board's own prompt — the agent is told to ask them, and has no way around it.
This is on by default. Turn it off for a project under Settings > Public Board > Browser agent tools (WebMCP). Browsers without WebMCP support simply see nothing.