{"site":{"name":"Koji","description":"AI-native customer research platform that helps teams conduct, analyze, and synthesize customer interviews at scale.","url":"https://www.koji.so","contentTypes":["blog","documentation"],"lastUpdated":"2026-09-28T00:58:05.487Z"},"content":[{"type":"documentation","id":"7d976b69-e5f8-473d-b013-c0cfa9a661ae","slug":"research-workspace-roles-permissions","title":"Research Team Collaboration: Workspaces, Roles and Who Can See What","url":"https://www.koji.so/docs/research-workspace-roles-permissions","summary":"A Koji workspace has exactly three roles - owner, admin and member - and every study is either workspace-visible or restricted to named people. Invitations can grant admin or member but never owner, keeping the highest privilege out of email. Nielsen Norman Group research across more than 400 UX and ResearchOps professionals found 29 percent of repositories had no owner and only 8 percent had a ResearchOps practitioner owning them, which is why explicit ownership matters more than tooling. Member groups model squads without adding permission levels, and workspace actions are written to an audit trail.","content":"A Koji workspace has exactly three roles - owner, admin, and member - and every study inside it is either visible to the whole workspace or restricted to named people. Those two settings do almost all the work of research collaboration. Get them right and your team reuses research; get them wrong and people either cannot find prior work or can see things they should not.\n\nThe single most useful thing to fix first is ownership, because that is where research repositories measurably fail.\n\n## Why ownership is the failure mode\n\nIn *Why Research Repositories Fail and How to Get Them Right* (Maria Rosala, Nielsen Norman Group, 26 July 2024), the author surveyed over 400 UX and ResearchOps professionals. Two findings stand out.\n\nThe first is that ownership is frequently absent altogether: \"29% of our respondents reported that their repository had no owner.\" The second is how rarely ownership is anyone's actual job - only \"8% of our respondents had a ResearchOps practitioner owning the repository.\"\n\nThe consequences show up in adoption. Rosala reports \"almost a fifth (19%) of our respondents felt that their research repository had poor adoption\", with only \"9% reporting mature and thriving repositories.\"\n\nRead those together and the diagnosis is not a tooling problem. A repository with no owner has nobody deciding what belongs in it, nobody enforcing a naming convention, and nobody to ask when a study cannot be found. The fix begins with making ownership an explicit, enforced property of the workspace rather than a convention someone is supposed to remember.\n\nThat is precisely what a role model gives you.\n\n## The three workspace roles\n\n### Owner\n\nThe owner is the top of the workspace. Ownership is the role that controls billing and the workspace itself, and it is deliberately the hardest role to hand out - more on that below. Every workspace should have an owner who knows they are the owner.\n\n### Admin\n\nAdmins run the workspace day to day: managing people, configuring defaults, and administering studies. This is the right role for a research lead or ResearchOps practitioner - the person Rosala's data suggests is usually missing.\n\n### Member\n\nMembers do research. This is the correct default for the large majority of a team, including engineers and designers who need to read findings and run their own studies without administering anyone else.\n\nThere is no viewer role. If your instinct is to give a stakeholder read-only access to everything, the mechanism you actually want is study visibility, covered below.\n\n## Invitations: what you can and cannot grant\n\nThis is the detail that surprises people, and it is worth knowing before you plan a migration.\n\nYou can invite someone as an admin or as a member. You cannot invite someone as an owner. Ownership is not a thing you hand out in an invitation email - it is a property of the workspace that has to be transferred deliberately.\n\n### Why the restriction is the right default\n\nAn invitation is a link sent to an email address. If ownership were grantable by invitation, the highest-privilege role in your workspace would be reachable by whoever controls an inbox. Separating *join the workspace* from *take over the workspace* is a straightforward application of least privilege.\n\n### What else an invitation carries\n\nInvitations are scoped and time-bound rather than open-ended. Each one is issued to a specific email address, moves through a defined lifecycle of pending, accepted, revoked, or expired, and can place the new person into member groups at the moment they join, so access does not depend on someone remembering a follow-up step. Invitations that are never accepted expire rather than remaining valid indefinitely.\n\n## Study visibility: workspace or restricted\n\nSeparately from roles, each study carries a visibility setting with two values.\n\n**Workspace** visibility means everyone in the workspace can see the study. This should be your default, and it is the setting that makes research reusable. The duplication problem Rosala describes - teams rerunning studies whose findings already exist - is largely a visibility problem wearing a discovery costume.\n\n**Restricted** visibility limits the study to named people. The workspace also carries a default visibility setting, so you can decide once whether new studies start open or closed rather than relying on per-study discipline.\n\n### When restricted is genuinely the right call\n\nRestrict a study when the participants are identifiable and the topic is sensitive - employee research about managers, exit interviews, anything touching health or finances. Restrict it when a commercial embargo genuinely applies, such as pre-announcement pricing work.\n\n### When restricted is a mistake\n\nDo not restrict a study because it is unfinished, or because the findings are unflattering, or out of vague caution. Default-closed research is the main reason repositories go stale: people stop looking in a place that has usually told them no.\n\nIf your concern is that raw transcripts contain personal data but the findings do not, the answer is not blanket restriction - it is [anonymising the interview data](/docs/anonymizing-customer-interview-data) so the study can safely stay open.\n\n## Member groups\n\nRoles answer *what can this person do*. Member groups answer *which slice of the work is this person part of*, which is what you need once a workspace outgrows a single team. A group has a name and description, and within a group a person is either a manager or a member.\n\nGroups are how you model a research guild, a product squad, or a regional team without inventing new permission levels. Note the group role is separate from the workspace role: being a group manager is about that group, not about the workspace.\n\n## Personal and shared workspaces\n\nA workspace is either personal or shared. Personal is the single-user case - the solo researcher or founder doing their own studies. Shared is the collaborative case with roles, invitations, and groups.\n\nThe practical advice is to move to a shared workspace earlier than feels necessary. Research done in a personal workspace is invisible to everyone else by construction, which is the most complete form of the discoverability failure above.\n\n## The audit trail\n\nWorkspace activity is recorded: who acted, what action was taken, who it affected, and when. This matters for two quite different reasons.\n\nThe first is security review. Enterprise buyers ask who can see interview data and how you would know if that changed - see [Enterprise Security for AI Customer Research Platforms](/docs/enterprise-security-ai-research-platforms).\n\nThe second is ordinary operational sanity. When a study's visibility changes or someone loses access, the useful question is not *who did this* in an accusatory sense but *what changed and when*, so you can put it back.\n\n## How Koji handles this\n\n- Koji enforces exactly three workspace roles - owner, admin, and member - so permissions cannot drift into a bespoke scheme nobody understands.\n- Invitations can grant admin or member only, never owner, keeping the highest privilege out of email.\n- Each study is workspace-visible or restricted, and the workspace carries a default so the safe choice is made once rather than per study.\n- Member groups let a large workspace model squads and guilds without adding permission levels.\n- Workspace actions are written to an audit trail, so access changes are reconstructable rather than folklore.\n- Because Koji runs the interviews as well as storing them, a study that is visible is immediately useful - the transcript, the structured answers across all six question types - open_ended, scale, single_choice, multiple_choice, ranking, and yes_no - and the report all travel together rather than living in three tools.\n\n## Common mistakes\n\n### Making everyone an admin\n\nThe most common one, usually done to unblock somebody quickly. It defeats the point of having roles and makes the audit trail much harder to reason about. Member is the right default in Koji; promote deliberately.\n\n### Leaving ownership implicit\n\nIf nobody can name the owner of your workspace, you are in the 29% Rosala measured. Name an owner in your Koji workspace, tell them, and make sure an admin exists who is not the same person.\n\n### Defaulting studies to restricted\n\nThis looks prudent and quietly causes the duplication it was meant to prevent. Default to workspace visibility and restrict the specific studies that genuinely need it.\n\n### Treating visibility as a substitute for data handling\n\nRestricting a study controls who can open it. It does not minimise what was collected or set how long it is kept. Those are separate obligations - see [Research Data Retention and Deletion](/docs/research-data-retention-deletion).\n\n## Frequently asked questions\n\n### What are the three workspace roles in Koji?\n\nOwner, admin, and member. The owner sits at the top of the workspace and controls billing and the workspace itself, admins manage people and studies day to day, and members do research. There is no separate viewer role - use study visibility instead if you want to limit what someone can open.\n\n### Can I invite someone directly as an owner?\n\nNo. Invitations can grant admin or member only. Ownership has to be transferred deliberately rather than handed out in an invitation, which keeps the highest-privilege role in your workspace from being reachable by whoever controls an email inbox.\n\n### What is the difference between workspace and restricted visibility?\n\nA workspace-visible study can be opened by everyone in the workspace, which is what makes prior research reusable. A restricted study is limited to named people. Your workspace also has a default visibility setting so new studies start the way you intend.\n\n### Who can see interview transcripts and personal data?\n\nAnyone who can open the study. That is why visibility, not role, is the control to reach for when a study contains identifiable or sensitive material - and why anonymising the data is often the better answer, since it lets the findings stay discoverable without exposing participants.\n\n### Do member groups replace roles?\n\nNo, they work alongside them. Roles decide what a person can do in the workspace; groups decide which slice of the work they belong to, such as a squad or a regional team. Within a group a person is either a manager or a member, and that is independent of their workspace role.\n\n### How do I prove who changed what?\n\nWorkspace activity is recorded with the actor, the action, the affected person, and a timestamp. This is what you show during a vendor security review, and it is also how you work out what to put back when someone unexpectedly loses access.\n\n## Related Resources\n\n- [Structured Questions Guide](/docs/structured-questions-guide) - the six question types every study in your workspace is built from\n- [Enterprise Security for AI Customer Research Platforms](/docs/enterprise-security-ai-research-platforms) - SOC 2, SSO and what vendor reviewers ask about access\n- [Anonymizing Customer Interview Data](/docs/anonymizing-customer-interview-data) - how to keep a study open without exposing participants\n- [Research Data Retention and Deletion](/docs/research-data-retention-deletion) - how long to keep interview data\n- [UX Research Team Structure](/docs/ux-research-team-structure) - centralised, embedded and hub-and-spoke models\n- [Managing Research Participants](/docs/managing-research-participants) - the operational view of a running study\n","category":"Research Operations","lastModified":"2026-09-27T03:38:12.417242+00:00","metaTitle":"Koji Workspaces, Roles and Permissions: Who Can See What","metaDescription":"How Koji workspaces, the owner, admin and member roles, and workspace vs restricted study visibility control who can see your research.","keywords":["research workspace roles","research team permissions","study visibility","workspace collaboration research","research repository ownership","ResearchOps access control"],"aiSummary":"A Koji workspace has exactly three roles - owner, admin and member - and every study is either workspace-visible or restricted to named people. Invitations can grant admin or member but never owner, keeping the highest privilege out of email. Nielsen Norman Group research across more than 400 UX and ResearchOps professionals found 29 percent of repositories had no owner and only 8 percent had a ResearchOps practitioner owning them, which is why explicit ownership matters more than tooling. Member groups model squads without adding permission levels, and workspace actions are written to an audit trail.","aiPrerequisites":["A Koji workspace with at least one study","Familiarity with running a study end to end"],"aiLearningOutcomes":["Assign the correct workspace role between owner, admin and member","Explain why ownership cannot be granted by invitation","Choose between workspace and restricted study visibility for a given study","Use member groups to model squads without inventing permission levels","Avoid the four common errors: blanket admin, implicit ownership, default-restricted studies, and confusing visibility with data handling"],"aiDifficulty":"beginner","aiEstimatedTime":"10 min read"}],"pagination":{"total":1,"returned":1,"offset":0}}