Invite your team
Inviting people is two decisions: what can they reach, and what can they change. dotby keeps those separate, so you rarely have to over-promote someone just to unblock them.
Invite a teammate
Section titled “Invite a teammate”Open Members from the sidebar and invite by email. They get an invitation, and join with the role you picked.
Each role includes everything below it:
| Role | Can do |
|---|---|
| Admin | Everything, plus workspace settings, billing, and managing members. |
| Manager | Everything a member can, plus managing workspace content. |
| Member | Full access to workspace data. The normal teammate. |
| Guest | No workspace-wide access. Sees only the projects they are added to. |
Most people should be members. Keep the admin count small — it is the role that can change billing and remove people.
Invite a client as a guest
Section titled “Invite a client as a guest”Guests are for people outside your company: clients, contractors, reviewers, agencies.
A guest sees only the projects you explicitly add them to. Not the workspace project list, not other teams’ work, not your internal channels. Add them to one project and that is the entirety of dotby for them.
Guests are free, so you never have to choose between keeping a client in the loop and paying for it. See pricing for the current details.
Private projects
Section titled “Private projects”By default a project is public: everyone in the workspace can find it and open it. That is the right default — most work benefits from being visible.
Some work does not. Set a project to private and it disappears for everyone without explicit access, including admins. Use it for the small number of cases that genuinely need it: an acquisition, a sensitive client, an unannounced launch, HR work.
A private project is hidden, not just read-blocked. Someone without access does not see it in lists, in search, or in cross-project rollups — an initiative’s progress bar shows them the total of the projects they can see, so the existence of the private project does not leak through a number.
A team is a named group of people — Design, Backend, Support.
Teams are a convenience, not a permission boundary. Their value is one handle
for many humans: mention @design in a comment and everyone currently in it is
notified, without you remembering who joined last month.
Give one person one extra ability
Section titled “Give one person one extra ability”Sometimes someone needs exactly one thing that their role does not include — seeing everyone’s logged time, or everyone’s pay rates.
You can grant those individually instead of promoting the person to admin. It keeps the “who can change billing” list short, which is the number that actually matters when someone leaves.
A setup that works
Section titled “A setup that works”For a team of about ten:
- Two admins — you and one other person. Never one; never five.
- Everyone else is a member.
- Clients and contractors are guests, on the one project they belong to.
- Projects are public unless there is a specific reason not to be.
- Teams for each real group, used for mentions.
- Core concepts — how roles, projects, and access fit together.
- Getting started — if you have not set up your first project yet.