Most teams converge on a simple pattern. One or two people hold owner status—typically the team lead or founding engineers. An operations or platform lead might be promoted to admin, getting day-to-day governance without the power to delete the workspace. Everyone else is a member, able to read and act on their authorised pieces—decide on routed items, edit knowledge, open pull requests—without touching the levers that steer the vehicle itself.
An owner has full control. You can manage any member on the team, promote or demote anyone to or from any role, change workspace policies, approve integrations and connect new providers, govern how knowledge flows through the system, and if necessary, delete the entire workspace. Owners are rare in practice; most teams want at least two so that vacation, job transitions, or plain human error don't leave the workspace in limbo. This preference isn't paranoia—it's a response to the last-owner protection described below.
An admin manages settings and membership without the nuclear button. Admins onboard people, revoke access, adjust policies, mint integrations, and decide what parts of the knowledge graph are sensitive. They cannot promote anyone to owner, cannot remove an existing owner, and cannot delete the workspace. An admin is the right fit for a platform or operations lead who runs day-to-day setup and configuration but doesn't need to own the workspace's existence. Think of it as trusted delegate without veto power.
A member reads everything in the workspace that isn't gated by access control and acts on the parts they're authorised for. Members can decide on Inbox items routed to them, edit knowledge, chat, open pull requests from a connected repo, and participate in the normal flow of work. Members cannot change workspace policy, install integrations, manage other members, or govern knowledge access. It's the right level for contributors who need to ship but don't need to steer.
The system enforces one hard constraint: there must always be at least one owner. If you're the last owner and try to demote or remove yourself, Ship refuses with a clear error: "This is the last workspace owner. Promote another member to owner first." The constraint is annoying once and saves you a support ticket. A workspace without an owner is an orphaned tenancy that nobody can administer—not even us. We can't fix it without either promoting you by fiat (which breaks the model) or deleting the workspace entirely (which is worse). The protection asks you to invest two minutes upfront: add a second owner before you do anything else interesting. The expensive habit is to discover at 11pm that you're the only owner and can't recover your account because you lost two-factor and have no fallback.
Inviting people is straightforward. Navigate to Settings, then Members, and use the invite form. You'll see a field for email, a dropdown to choose the role, and the workspace name pre-filled. The invite email that lands in their inbox carries the workspace name, your identity, and instructions to accept. From there, the gotcha is timing: promoting someone to admin or member takes effect immediately, so they can see the workspace as soon as they accept. Owner promotion, by contrast, goes through a confirmation step—the new owner receives a separate message and must opt in. This asymmetry exists because giving someone full control over deletion and policy should never be a surprise baked into an invite; it's a decision worth confirming.
The cheap habit is to invite the second owner first, before you do anything else. You set up a workspace, you add a coworker as owner right away, and you're done worrying about single points of failure. The expensive habit is to build out your workspace alone, layer in integrations, connect to your repos, seed knowledge, and then weeks later realize that only you can manage the account. Protect your future self: add that second owner while the workspace is still clean and you have time to verify their two-factor is set up.