Roles and permissions for game development teams

Why access control gets messy in a game studio

A game team is rarely just a list of employees. On a typical production you have a core team, a few freelancers, an outsourcing partner that delivers art, a QA vendor that only needs the bug tracker, a composer, and sometimes a publisher producer who wants to follow progress without touching anything. Each of them needs a different slice of the project.

The usual failure is not a dramatic breach. It is drift. Access is granted in a hurry on a Friday, nobody removes it when the contract ends, and after two years nobody can say who can read the design documents or who can submit to the depot. The second failure is the opposite: permissions so coarse (everyone is an admin, or nobody can do anything without asking) that people share accounts to get their work done.

What a good permission model for a game team needs

• Separate "who manages the organization" from "what someone can do in a feature". Being allowed to invite people is a different responsibility from being allowed to approve voice takes.
• Scope by project. A contractor on one title should not see the next one.
• A real read-only tier. Stakeholders and auditors should be able to look without any risk of changing something.
• Named roles that match the org chart. "Producer", "QA Lead", "Voice Director" are easier to review than a list of checkboxes per person.
• A record of changes. When a role is assigned or a user is created, someone should be able to see who did it.

Version control adds one more layer. On a Perforce server, the protections table decides which depot paths a user can read or write. That table is the right place for path-level rules, and the project-management tool on top of it should respect it rather than replace it.

How Gameheim handles roles and permissions

Gameheim combines three things. The Roles & Permissions page sums it up as a formula: the tier, plus the custom roles you manage, gives the effective permissions of each person.

Organization tiers: LEAD, MEMBER and VIEWER

Every account has one tier, set by a LEAD in User Management. The tier decides how much the custom roles can give.

Custom roles built from granular permissions

A custom role is a named set of permissions, defined once for the whole organization and assigned to as many people as you like. The catalogue has 63 permissions grouped by feature area: Voice Acting, Calendar, Tasks, Bugs, Decisions, Topics, P4 Workspace, Git Workspace, Plugins, Moodboards, Wiki, Documents, AI, Changelist Templates, Music & SFX, Capacity Planning, Announcements, External apps (MCP & API), Dashboard, Audit Log, Org Settings, Users and Roles.

Inside each group the permissions follow the verbs of that feature. Most areas have read, write and manage (where manage usually covers deleting and curating). Some go further because the work is different: the P4 Workspace splits into browse, checkout and submit; the Git Workspace into browse, commit and push; Voice Acting has separate permissions to edit lines, upload takes, bind lines to Unreal Engine assets and review translations; Bugs has crash_files, which gates the minidumps and game logs attached to crash reports while the callstack stays visible to anyone who can read bugs.

Every new organization starts with eight roles you can edit: Team Member (Default), Producer, QA Lead, Animator, Programmer, Sound Designer, Designer and Voice Director. Team Member (Default) is a system role: you can change its description and permissions but not rename or delete it. It is pre-selected when you invite someone, so a new person lands with a sensible baseline (dashboard, tasks, bugs, decisions, topics, calendar, the P4 Workspace, and read access to moodboards, voice acting, wiki and documents).

Project membership

Roles say what someone can do; membership says where. A MEMBER or VIEWER only sees the projects they have been added to, and their permissions apply inside those projects. A LEAD sees every project in the organization. Nothing crosses organizations: each studio is isolated from every other.

Finer controls inside some features

• Wiki pages have Page permissions with four access modes: Public, Inherited, Read-only and Restricted (only the users granted can see the page).
• Moodboards can be Private, visible only to admins, the creator and the users or roles you add in Manage access.
• Topics (channels) can be private.
• Project Administration for a Perforce project is opened per person from the Team page with Panel access. It is a ceiling, not a privilege: what someone can actually do is still decided by their rights on the Perforce server.

Two more things narrow what a role can grant. First, your plan: a permission for a feature your plan does not include is removed for everyone in the organization. Second, a person who manages roles but is not a LEAD cannot grant a permission they do not hold themselves; the editor shows those checkboxes as locked.

How to set up roles and permissions in Gameheim

This walkthrough creates a role for an outsourcing art partner, gives it to a new person and limits them to one project. The same steps work for any role.

1. 1

   Open Roles & Permissions

   In the sidebar, under Administration, open Roles & Permissions. The first time, a panel titled How roles work in Gameheim Hub explains tier, custom role and effective permissions. You can dismiss it.

2. 2

   Create the role

   Click + New role. Give it a Name (for example "Outsource Artist") and a Description that says who it is for. Under Permissions, tick what the partner needs: tasks:read and tasks:write under Tasks, browse, checkout and submit under P4 Workspace, moodboards:read under Moodboards. Leave Wiki, Documents and Capacity Planning unticked if they should not see your design documents or your planning. Click Create role.

   Tip:Start from what the person must do this week, not from what they might need one day. Adding a permission later takes a minute; noticing one that should never have been granted can take months.
3. 3

   Invite the person with the right tier

   Open User Management and click Invite User. Fill in Username and Display Name, add an Email, pick a Discipline (Art, Design, Programming, Audio, QA or General) and set Role to MEMBER. Under Add to projects (optional) tick only the project they work on. Under Assign roles (optional), untick Team Member (Default) if you want the new role to be the only source of permissions, and tick your new role. Click Create User.

   Gameheim shows an invite link that expires in 24 hours and can be used only once. If you entered an email, the invite is also sent there.

4. 4

   Check the effective permissions

   In User Management, use the Manage custom roles action on the person's row. The Roles for dialog lists Assigned roles and an Effective permissions preview, with a banner that explains what their tier does to the result. This is the fastest way to answer "what can this person actually do?".

5. 5

   Adjust project membership over time

   Use Manage project assignments on a row to add or remove projects for one person, or select several rows and use Assign Project to add them in bulk. When a contract ends, Deactivate keeps the person's data but stops them signing in and frees their seat; you can Reactivate them later.

Role examples for outsourcers, contractors and QA

These are starting points, not presets. Adapt them to how your studio works.

What a read-only (VIEWER) account can do

A VIEWER keeps only the permissions whose action does not change anything: read, browse (looking at the depot or the Git history without syncing changes back), and the capacity-planning view across disciplines. Everything else is removed on the server, whatever roles are assigned.

• A VIEWER can open tasks, bugs, decisions, wiki pages, documents, moodboards and the dashboard of their projects, if their roles include the matching read permission.
• A VIEWER cannot create or edit tasks, submit or push, upload files, publish announcements or post in topics.
• A VIEWER can never connect an external app (an AI assistant or a script) to Gameheim, because that permission is not read-only.

How Gameheim roles relate to Perforce protections

Gameheim does not replace the protections table of your Perforce server. Each person enters their own Perforce credentials for a project, and the agent runs commands as that Perforce user. Gameheim permissions decide which buttons a person can use (for example, whether they can submit from the browser at all); the Perforce server still decides which paths they can read and write. Keep path rules on the server and feature rules in Gameheim.

Troubleshooting: "I gave them the permission and they still cannot do it"

• The person is a VIEWER. Write and manage permissions are filtered out. Change the tier to MEMBER in User Management.
• The person is not a member of the project. Roles apply only in projects they belong to. Check Manage project assignments.
• Your plan does not include the feature. Permissions for features outside your plan are removed for everyone. See pricing.
• The Perforce server refuses the command. The protections table has the final word on depot paths.
• A checkbox is locked in the role editor. You cannot grant a permission you do not hold yourself. Ask a LEAD.

Frequently asked questions