Who sees what — the access model

Projects can be shared with teams and individual users. Access inherits to sub-projects and tasks, with one read-only ceiling over all grants.

Org admin — everything, everywhere, plus Organization settings (users, seats, billing, teams, labels, week settings).
Team leader — runs one team and its members. A team's membership can be shared with projects, but team leadership does not grant project authority.
Team access — add a team as User or Viewer and its members receive that role on the project. New members receive it automatically; removing a member removes that route to access.
Individual access — 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 administrator for identity, sub-projects and deletion). Each project and sub-project has one named lead. A parent project's lead and its explicit user or team grants inherit Edit/User access to descendants unless the descendant has its own stronger role; a grant made only on a child makes the parent visible for read-only navigation and never opens sibling projects.

Project access in project settings keeps these grants in one list, grouped under Teams and Users, with one Add team or user picker. You can share with several teams and add people individually, including someone outside those teams. The strongest applicable role wins: a Viewer team grant does not reduce an individual User grant. Removing a team grant leaves individual grants and access through other teams intact.

Who can change project access: organization admins and the named project lead can manage direct users, team shares and invitations. Team leadership does not add project authority. Handing the project lead to another person automatically retains the outgoing lead as a User. A team share can still affect the caller's inherited access.

Access-administration permissions do not grant the right to rename, archive or delete a project, edit its other settings or manage sub-projects. Those actions still require project Lead access. Removing someone's direct grant also does not remove authority they hold as an organization admin.

Sub-project access: a sub-project has its own named lead just like its parent and has no owning team. Add one or more teams to its Project access list when a workstream needs shared access; product sharing remains an explicit choice. A parent lead or parent grant carries Edit/User access down to it, but a child-only grant exposes only the parent shell for read-only navigation and never a sibling.

Project settings starts with Name. Sub-projects appears above Project access, with a divider above and below.

New project asks for a name, lead and optional Project access shares; it has no Managing team. Its Project access dropdown supports multiple team and individual selections, with Teams first and individual Users below. A New sub-project asks for a lead; add optional Project access shares in its settings. Changing sharing on an existing product is explicit: existing projects are not automatically opened to every team.

Exactly one named lead per project or sub-project: promoting someone else automatically steps the current lead down to User. One accountable owner at each level, always. An active guest who has a project grant can be selected as that lead in project settings.

The ceiling: a Viewer of the organization. Above these grants sits one setting on the person (§14). Make someone a Viewer and they read the projects they can access, including through a team, 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. A Viewer organization role does not make otherwise unshared projects visible.

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. There is no purchased-seat limit on adding or reactivating users: billing counts active users at monthly renewal, including pending invitations. A new login can create an organization of its own (below), but cannot award itself membership 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 Viewer or User. After they have been added, someone authorized by the organization's project-access policy can promote them to Lead in the Users list. 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 appear in the separate Guests list rather than your organization's member roster.
An active guest is billable only while they have no active membership in an organization of their own. Qivo matches their email address, so this also works before they sign up. An active home membership exempts them from your user charge; deactivating that home membership makes them billable to inviting organizations. If several organizations invite the same person and they have no active home membership, each inviting organization counts them. Billing lists billable and non-billable account names separately, without revealing another organization's identity or membership details.

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.