Permissions and Visibility
Understand how identity, board visibility, roadmap visibility, guest interactions, internal comments, tag visibility, and embed access work in Boarbs.
Most access questions in Boarbs come from mixing together three separate things:
- who the person is
- which surface they are using
- whether the item is public or team-only
The Three Identity Types
Boarbs resolves portal identity into three buckets:
| Identity | What it means | Typical surface |
|---|---|---|
team_member | Signed-in user who belongs to the organization | App dashboard and portal while signed in as a member |
end_user | Signed-in user who does not belong to the organization | Public portal or embed |
guest | No session | Public portal |
There is no single global permissions editor controlling all of this today.
Settings → Permissions exists, but the real rules currently come from organization membership, board visibility, roadmap visibility, tag visibility, internal comments, and the guest interaction toggle.
The Main Visibility Controls
| Item | Visibility model | What it changes |
|---|---|---|
| Board | PUBLIC or PRIVATE | Whether the board appears on the public portal and whether non-members can submit into it |
| Roadmap | EVERYONE or TEAM_MEMBERS | Whether the roadmap is visible publicly or team-only |
| Comment | Public or internal | Whether the discussion is visible to portal users or only to your team |
| Tag | Public or private | Whether the tag can be shown publicly or only internally |
Public Portal Rules
The public portal is where the guest interaction setting matters most.
| Situation | What happens |
|---|---|
| Public board + guest interactions enabled | Guests can submit, vote, comment, and subscribe by providing an email |
| Public board + guest interactions disabled | People can still view, but they must sign in before they can vote, comment, or subscribe |
| Private board | The board does not belong to the public portal flow |
| Post marked as spam | The post disappears from the public board and is not listed under Canceled |
Signed-in non-members can still interact with public boards because they count as end_user, not as team members.
Guests are the only case controlled by Settings → General → Allow guest interactions.
Private Boards
A private board is the cleanest way to keep a workflow internal.
In practice that means:
- it does not show up on the hosted public portal
- guests cannot create posts there
- signed-in non-members cannot create posts there
- team members can use it inside the app as an internal board
Use a private board when the audience is your team, not your customers.
Roadmap Visibility
Roadmaps have their own visibility model.
| Roadmap visibility | What it means |
|---|---|
EVERYONE | Public roadmap route can be shown to users |
TEAM_MEMBERS | Keep the roadmap internal to your workspace |
Roadmap visibility is separate from board visibility.
A public roadmap can still feel selective because columns can be hidden and filters decide which posts appear in each roadmap or column.
Public vs Internal Collaboration
The cleanest mental model is:
- public boards and public comments are for external discussion
- private boards, internal comments, assignees, and internal notes are for team work
- private tags are for internal organization
That lets you stay transparent without turning every internal decision into public discussion.
Tag Visibility
Tags are not only labels. They also have visibility.
| Tag type | Who can see it |
|---|---|
| Public tag | Safe to expose in public-facing views |
| Private tag | Only visible to your team |
Use private tags for internal segmentation like account tier, escalation state, or source system mapping.
Portal vs Embed Access
Embed follows a different rule set from the hosted portal.
On embed:
- your backend creates the session
- your backend supplies the user identity
- the session can target a public board or a private board owned by the same organization as the API key
That means the guest interaction toggle is a portal rule, not the master switch for every surface.
The same embed session can also start a hosted portal end_user session. That flow never signs in organization members. See Automatic Login.
Good Default Setup
If you want a clean, low-confusion rollout, start with:
- one public board for customer-facing intake
- one private board for internal team intake
- guest interactions enabled on the public portal
- one public roadmap for shipped and planned work
- internal comments and private tags for team-only context
Common Misunderstanding
The most common mistake is expecting public and visible to everyone everywhere to mean the same thing.
They do not.
Boarbs separates:
- public portal visibility
- roadmap visibility
- guest interaction ability
- internal vs public discussion
- API or embed access
That separation is what gives you a usable public workflow without losing internal control.
Next Steps
- Settings Reference — See where each control lives in the app
- Troubleshooting — Debug missing boards, blocked actions, and empty views
- Portal — See how these rules show up on the hosted public surface
