Who sees what — the access model

Three tiers, everything inherited downward — and one ceiling over all of them.

• Org admin — everything, everywhere, plus Organization settings (users, seats, billing, teams, labels, week settings).
• Team leader — runs one team: its settings, members, the projects it owns and their roles. (Plain team membership grants nothing at all — it marks who works in the team, and is not even a precondition for holding a project role.)
• Project roles — per user on each project: Viewer (read everything, change nothing — the controls that would change something are disabled), User (create and edit tasks, comment, attach, plan), Lead (the project's admin — identity, roles, sub-projects, deletion). Roles inherit to all sub-projects and their tasks.

Exactly one lead per project: promoting someone else automatically steps the current lead down to user. One accountable owner, always.

The ceiling: a Viewer of the organization. Above all three tiers sits one setting on the person (§14). Make someone a Viewer and they read exactly the projects they were added to and write nothing — whatever a project role, a lead title or a team leadership would otherwise have given them. It is not a kind of access, it is a limit on access: it never opens a door, it only refuses to let another one open wider than reading. So a viewer still needs to be added to a project to see it at all, and adding them is how you share.

Read-only is visibly read-only, not merely refused. A viewer's boards and roadmaps look the same and open the same, but the controls that would change something are disabled and say why: cards don't lift off the board, roadmap bars open on a click and never drag, the task window shows every field's value without letting you move it, and the New task / sub-project / milestone buttons aren't there. (The same is now true of a project-level Viewer role, which used to offer live controls whose every change was undone a moment later.)

A project you're not granted doesn't exist for you — absent from the sidebar, palette, boards, pickers and feeds; even a deep link won't resolve. But hidden work still occupies people: capacity views and delay projections count it anonymously — the PlanCard shows an unnamed "Other projects" bucket, hours only.

Inside an organization, membership is admin-provisioned: an admin adds people in Organization → Users, seats are counted from the active ones, and adding stops at the cap. What a new login can do is create an organization of its own (below) — never award itself a seat in yours.

People outside your organization#

Some of the people you work with don't work for you — a client, a contractor, a partner's engineer. You don't want them in your organization; you want them in one project.

Open the project's settings and invite them by email address, choosing the role they'll hold there (Viewer, User or Lead) exactly as you would for a colleague. Anything else follows from that role and stops at that project:

• They see the project, its sub-projects and its tasks. None of your other work exists for them — no other project, no plan, no capacity numbers.
• What they do see beyond it is what collaborating there requires: your organization's name, your people's names and email addresses (so tasks can be assigned, comments attributed and the right person @mentioned — the mention list shows the address under the name) and your label vocabulary — which they can apply but never rename or delete.
• They aren't in any team, they can't open Organization settings, the user list or billing, and they can't create projects.
• A User-level guest is a full working participant there: tasks, comments, attachments, milestones, planning.
• They don't take one of your seats — a guest never counts against your organization's roster limit, and never appears in it.
• What they cost depends on whether anyone else is already paying for them. A person is paid for once. If your guest holds a seat in their own Qivo organization — the usual case for a client or a contractor who uses Qivo themselves — that organization is already paying and you pay nothing. If they have no organization of their own, they count as a user on your bill, because yours is the only organization they are in. And if two companies both invite the same person and that person has no organization of their own, both pay for them: splitting it would mean two unrelated companies knowing about each other, which costs more complexity than the case is worth.

You can invite someone who has never used Qivo: the invitation waits for the email address, and the moment they sign up it's theirs. Existing users get it on their next visit — nothing to accept, no second account to make.

On their side, an invited project simply appears in the sidebar they already have, under a small header naming the organization that shared it. There is no "switch organization" menu to hunt for, because there is no mode to be in — their own work and their guest work sit in one list, one board, one roadmap, one capacity picture. Removing the grant removes the project from their world just as completely as any other revoked access.

Your own account: you sign up, and if no one is expecting you, Qivo offers to create your organization — you become its first admin, with a first team ready to hold projects. That home organization is yours for good; further organizations reach you as a guest, by invitation, never by switching.

✦ What sets this apart — Hidden projects stay hidden and the capacity numbers stay right: most tools either leak confidential project names into workload views or silently ignore invisible work — Qivo does neither. And the single-lead rule means every project has exactly one accountable owner.

✦ Guests without the mode-switching — External collaboration usually means either a separate "client portal" with a thinner product in it, or an organization switcher that makes people ask where am I? before every click. Qivo gives guests the real product, scoped to one project, and shows it in the same single list as everything else they do.