This isn't a how-to article, it's a how to think about it article. The mechanics of inviting people and granting per-game access are covered elsewhere (see Inviting and managing team members and Sharing access on a game). Here we cover the question that actually matters: which role should I pick, and what should this person be able to see?

Get this right and your team moves fast without exposing your whole portfolio. Get it wrong and you either share too much (publishers and playtesters seeing work-in-progress they shouldn't) or share too little (artists and co-designers constantly blocked on you).

What this page helps you do

Pick the right role for each person you're bringing in.
Decide whether to scope someone to one game or give them the whole portfolio.
Set yourself up for less back-and-forth, fewer surprises.

The core trade-off

You have two levers:

Role at the team level, Member sees everything in the team. Collaborator sees only what you grant per-game. (Owner and Admin see everything plus manage settings; we'll mostly ignore those here since they're for your own inner circle.)
Per-game access for Collaborators, for each game, you can grant a Collaborator view-only or edit access, or none at all.

The trade-off:

More access = faster collaboration, less of you being the bottleneck, but more visibility into things you might prefer to keep private.
Less access = stronger boundaries between your projects and your guests, but more friction every time someone needs something they can't see.

Default to the least access that lets the person do their actual job. You can always grant more later; clawing access back is awkward.

A decision flow

Walk through these in order:

1. Are they part of your inner team?

Inner team = people who help with your overall strategy, multiple games at once, and need to see the big picture. Co-founders, in-house designers, permanent project managers, full-time artists.

→ Make them an Admin (or Member). They get the whole portfolio. Don't fragment their access.

2. Are they working on one specific game?

One-game contributors = freelance artists, single-game editors, an illustrator hired for one project, a consultant reviewing one design.

→ Make them a Collaborator, then grant access to that one game only. They won't see your other in-progress work, and removing them when the project ends is one click on that game's permissions, not a team-wide reckoning.

3. Are they a publisher or external rep with privileged access?

Privileged externals = a publisher you're in serious talks with who wants to track progress on one game, a manufacturer who needs to review a specific component spec.

→ Collaborator with view-only access to the relevant game(s). They see what you want them to see, can't accidentally edit anything, and you can revoke access cleanly when the conversation ends.

4. Are they running playtests for you?

→ Collaborator with edit access to the games being playtested. They can schedule playtests, review feedback, and add notes, but won't see games they're not running.

For external playtesters themselves (the people filling out forms), remember: they don't need a Boardssey account at all. Share a feedback form link and you're done. See For external playtesters (in the Playtest collection) and Logging external playtester data manually for those flows.

5. None of the above, you're not sure?

Default to Collaborator with one-game access. It's the safer baseline. You can always promote them later when you know the relationship better.

Patterns that work well

A few patterns we see that hold up:

One game per freelancer. When you bring on a new freelancer, create or pick the one game they're working on, add them as a Collaborator with edit access to just that game, and never touch the rest of their permissions. Clean, predictable, low overhead.
Publisher review = view-only. Always view-only, never edit. A publisher shouldn't accidentally rewrite your rules.
Co-designer = Member, full stop. If you genuinely have a co-designer, they need the whole picture. Trying to scope them to a single game creates invisible friction every time they want to compare across projects.
Annual cleanup. Once a year, scan your member list and per-game grants. Remove anyone whose project is done. Reduces surface area and keeps the workspace tidy.

Patterns that backfire

Adding everyone as a Member to "make things easier." Easier today, awkward later, when an artist you parted ways with is still in the team and can see the new game you didn't tell them about. Default to least access.
Forgetting to revoke per-game access at project end. A Collaborator removed from the team is fine. A Collaborator still in the team but never un-granted on a game is invisible long-tail exposure. Use Sharing access on a game to revoke when projects finish.
Multiple separate teams to "isolate" projects you could just scope. If the only reason you'd run multiple Boardssey teams is to keep certain collaborators away from certain games, use the Collaborator role + per-game permissions instead. Multiple teams means multiple subscriptions for no real gain.

What this looks like in practice

A small studio with one designer, two freelance artists (each on a different game), and one external playtest organizer might look like:

Role	Who	Access
Owner	The studio's founder	Everything
Member	Co-designer	Everything
Collaborator	Artist A	Edit access to Castle Project only
Collaborator	Artist B	Edit access to That coop idea only
Collaborator	Playtest organizer	Edit access to whichever game is currently in playtest

When Castle Project ships, Artist A is removed from that game's permissions (and possibly from the team entirely). Their work stays. Their access doesn't.

Tips & common questions

Should I add a publisher as a Collaborator before they sign? Generally no, share a sell sheet or a public catalog link instead. Bring them in as a Collaborator with view-only access only when the relationship moves to "actively negotiating, want to track progress."

Can a Collaborator see who else is on the team? They can see the people they share games with (via the per-game permissions list). They don't see the full team-wide member list.

An artist I removed wants their work back. What can I share? Their uploads (cover art, component images, etc.) live in your team workspace, not theirs. You're free to share files back with them as you would any deliverable.

My team has gotten messy, too many old members and grants. Where do I start? Open Members, sort by last activity if available, and remove anyone who hasn't worked with you in 6+ months. Then open each active game and review the per-game permissions list there. Stop when nobody surprises you.