Board Visibility
The Board Visibility Settings allow you to control who can access and interact with your board, providing flexibility to either keep your project private, share to dedicated guests or share it publicly.
#Private Board
- When a board is set to private, only authorized team members have access.
- This is ideal for internal projects where you want to control and restrict access to sensitive data, discussions, or development tasks.
- Any external public users cannot see, access, or interact with the board or its content.
#Public Board
If you change the visibility to Public, the board becomes accessible to everyone via a public URL. However, several restrictions are automatically applied:
- Hidden Notes and Archive: The "Notes" and "Archive" sections will be hidden from public users. These sections often contain internal documentation or previously completed/archived tasks that are not relevant to external viewers.
- Hidden Comments: Comments on tasks will also be hidden to protect sensitive communication between team members.
- Fictional Names: For privacy, the names of the board members will be changed to fictional ones when viewed by the public.
- Limited Interaction: Public users will not be able to add, delete, or edit anything on the board. They will have read-only access, making this feature ideal for transparency while maintaining control over the project's integrity.
#Advantages of Public Boards
Making your board public can offer various advantages, especially for open-source projects, educational purposes, or for marketing reasons. Some key benefits include:
- Transparency: Public boards promote transparency, allowing stakeholders, customers, or contributors to see the progress of a project.
- Collaboration: By making a board public, you encourage community engagement. People outside your organization can observe and offer feedback or even contribute to specific tasks, depending on your project goals.
- Showcasing Work: For agencies or freelancers, a public board can serve as a portfolio, demonstrating ongoing or completed work to potential clients.
- Real-Time Updates: Public users can view real-time progress without needing access to internal communications, making it easy to keep stakeholders informed.
#Public Tasks
When Public Tasks are enabled, users with a t0ggles account (if board is public) or guest users (if board is private) can submit tasks to a board. These submissions require team approval before appearing on the board. This is useful for collecting feature requests, bug reports, or** general feedback** from external users.
To enable Public Tasks, go to:
Board Settings → Visibility → Public Tasks
- Toggle Public Tasks ON
- Customize the Button Text (default: "Suggest a Task") to match your use case, e.g., "Submit Issue", "Feature Request", or any other relevant action
Once enabled, public users can propose tasks, which will be pending approval by the team. If a submission is accepted, it will appear on the board like any other task.
💡 Note: Public users must be signed in to submit tasks.
#Guest Users
Instead of making the board Public, you can add Guest users to the board. They will have the following permissions and restrictions:
- They can see the board projects and tasks,
- They can suggest tasks (if Public Tasks are enabled),
- They can see the real names of the Board members.
- They can see and leave comments on tasks.
- The "Notes" and "Archive" sections of the Board will still be hidden for guest users.
- Guest users will not be able to add, delete or edit Tasks.
#Public Views
Here you can control which views are visible to public and guest users.
- Board View: The Kanban board view will be visible to public and guest users.
- List View: The list view will be visible to public and guest users.
- Gantt View: The Gantt view will be visible to public and guest users.
- Calendar View: The calendar view will be visible to public and guest users.
If none of the views are enabled, the default Kanban view will be visible to public and guest users.
The Board Visibility Settings offer a balance between security and openness, depending on the needs of your project. For instance, internal projects can remain private for operational reasons, while community-driven or open-source projects can be made public for external collaboration and transparency.