Team Roles, Seats, and Permissions

The moment a second person needs access, you have a decision you did not have before: what should they be able to break?

Cosmic's permission model has two layers, project and bucket, and getting the shape right early saves the awkward conversation later about who deleted the object type. This lesson covers inviting people, choosing roles, and the seat math, including where AI agents fit.

---

Before You Start

• Project Admin or Manager access. Those are the only roles that can invite

• Someone to invite. A second email address of your own works fine for trying this

---

Step 1: Open the Team Page

Click Team in the project sidebar.

If you do not see it, your project role is User, which cannot manage members. Admins and Managers see it. It is also hidden on projects owned by a workspace, where membership is managed one level up.

The table lists everyone with access, their role, and their status. People who have not accepted yet show Invite pending... and count against your seats from the moment you invite them.

---

Step 2: Invite Someone

Click Invite team. The Add team member drawer opens.

Enter their email, then choose a role under Project permissions:

Admin gets everything a Manager can do, plus project usage, settings, and billing.

Manager has access to all buckets, can add buckets, and can manage members. This is the right role for someone running the content operation who should not see the invoice.

User has access to specific buckets only and cannot create new ones. This is the role you will use most, because it is the only one that lets you scope access.

Click Send invite. They get an email with an Accept invitation button, and you get a shareable invite link in case the email goes astray.

---

Step 3: Scope a User to Specific Buckets

Choosing User reveals a Bucket permissions section. It starts empty, with the message Select a Bucket to add permissions. Nobody gets access to anything until you grant it explicitly, which is the right default.

Add a bucket and pick a role within it:

The distinction that matters most is Editor versus Developer. An Editor works with content. A Developer changes the shape of content by editing object types and metafields. A freelance writer does not need to be able to delete a metafield, and giving them Developer access means they can.

Contributor is the tightest role. You pick which object types they can touch, and they can only edit content they created. This is the right choice for guest authors and anyone you have not worked with before.

---

Step 4: Two Restrictions Worth Knowing

Under Additional permissions for a Developer or Editor, there is a Settings checkbox that grants access to bucket settings and destructive actions. Leave it off unless there is a specific reason.

For Editors there is a Publishing restrictions section with Save content to Draft status only. This gives someone full editing ability while keeping the publish decision with your team, which is often exactly the arrangement you want with an agency or contractor. They do the work, you decide when it goes live.

---

Step 5: Understand Your Seats

Go to Usage in the project sidebar. Under Team members you will find Seats in use showing how many of your allowance you have used.

Check that number before planning a rollout, because pending invites count. If you invite five people and three never accept, you are still paying for five seats until you remove the stale invitations.

Seat allowances come from your plan, and extra seats are purchased under Billing > Add-ons in the Team seats section. Current allowances and prices are on the pricing page rather than in this lesson, since they change.

If you try to invite someone with no seats left, you will see You need to add a seat in order to invite this member and a prompt to add one.

---

Agents Do Not Use Seats

This is the part most people assume wrong, and it changes how you staff the operation.

AI agents do not consume a human seat. They are counted separately, as Team agents, with their own allowance shown on the same Usage page. Only active agents count against it, so pausing one frees the slot. Adding an agent that drafts posts does not cost you a seat that a human editor could have used.

The practical implication is worth thinking through. When a recurring task needs doing, the question is not only "who do we hire" but "is this a job for an agent." Research, drafting, translation, and content audits are jobs an agent does well and does not need a seat for. Judgment calls, approvals, and relationships need a person.

There is no combined view of humans and agents. People live on the Team page, agents live under Agents, and Usage tracks the two allowances separately.

---

A Tip on Choosing Roles

The instinct is to give people the access they might eventually need, because it avoids a follow-up request. Resist it for one specific reason: the roles are trivially easy to upgrade and awkward to downgrade.

Granting more access takes ten seconds and nobody objects. Taking access away is a conversation about trust, even when it is really about tidiness. So start people at the narrowest role that lets them do today's work, and widen it when they ask.

A default that works for most teams: content people get Editor on the buckets they work in, developers get Developer, external contributors get Contributor with Save content to Draft status only if they need broader editing, and Admin stays with the one or two people who handle billing.

---

Going Further

Both the Team page and the workspace team page have Import team CSV for onboarding a group at once. The columns are , , , and , where role is , , or . There is a review step before anything is sent, and it will tell you if the import pushes you past your seat count.

Several sidebar sections are admin-only and will simply not appear for other roles: Agents, Workflows, Code, Insights, Billing, Usage, and Settings. Worth knowing before someone reports a missing feature that is actually a permission.

If your organization uses workspaces, the same three role names exist one level up, at , controlling access across projects rather than buckets.

---

Do This in Your Project

1. Go to Team and click Invite team

2. Enter an email and choose User rather than a broader role

3. Under Bucket permissions, add one bucket and set the role to Editor

4. Check Save content to Draft status only

5. Click Send invite

6. Open Usage and look at Seats in use to see what that invitation cost you

Then look at the Team agents number beside it. That is the capacity you have that is not competing for seats.

---

Up Next

Lesson 13: Localization and Publishing Operations

The final lesson covers running content in more than one language, and the safety net you want before anyone can publish a mistake.