Use Private Feedback Boards
Keep internal ideas, planning, and sensitive requests inside your workspace without exposing them on the public portal.
Private boards are for feedback that should stay inside your team workspace.
They are useful when the work itself is internal, not merely when you want a lighter sign-in requirement.
What “Private” Means in Boarbs
When a board is PRIVATE:
- it does not appear on your public portal
- it is not exposed through the public board views
- guests cannot submit into it
- authenticated users who are not members of your workspace cannot submit into it
- your team manages it from the app, not from the public portal
This makes private boards a strong fit for internal intake and planning.
Good Use Cases
Private boards are especially helpful for:
- internal product ideas
- support escalations before they become public requests
- internal bug or ops intake
- leadership or roadmap planning that should stay team-only
- feedback imported from other channels before it is ready for public visibility
When a Private Board Is the Wrong Tool
Do not use a private board when you actually want public visibility with tighter participation controls.
In those cases, keep the board public and adjust interaction rules instead.
Typical examples:
- a customer-only feedback area where the board should still be visible
- a closed beta where you want people to browse requests but sign in before acting
- a roadmap-backed public board that should stay discoverable
How to Create One
- Open Settings → Boards
- Create a new board or open an existing one
- Set the visibility to
PRIVATE - Save the board
You can still give the board a description and icon like any other board.
Suggested Structure
For many teams, the cleanest setup is:
- one public board for customer-facing requests
- one private board for internal planning and sensitive intake
This keeps the public experience simple while giving the team room to work.
What to Keep on the Private Side
A private board is often the right home for:
- rough ideas that are not ready for public wording
- duplicates and support escalations that need cleanup first
- early planning work before customer communication starts
- internal-only issues that should never appear on the roadmap
Common Mistake
Some teams create a private board when what they actually need is:
- a public board
- guest interactions turned off
- sign-in required before voting or commenting
That setup still lets customers see the discussion, while private boards hide it completely.
Next Steps
- Collect Guest Feedback — Decide whether public boards should allow guest participation
- Create Boards — See when another board is truly worth the complexity
- Triage Feedback — Keep internal and public intake flowing cleanly