> ## Documentation Index > Fetch the complete documentation index at: https://greatquestion.co/support/llms.txt > Use this file to discover all available pages before exploring further. # User Roles and Permissions > Understand the roles in your workspace and what each one can do. Great Question uses role-based access control to manage what people can see and do in your workspace. Every member has one of four roles, and Admins can fine-tune access further through workspace settings. ## The roles | Role | Seat | What they can do | | --------------- | ---- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | **Admin** | Paid | Full control of the workspace — billing, members, data visibility, branding, and governance settings. | | **Creator** | Paid | Create and manage studies and contribute to the repository. Can invite new members as **Observer**, create email templates, fund and approve studies by default, and view team wallet balances. Cannot access billing, manage other members' roles, change workspace settings, delete candidates, or create teams. | | **Observer** | Free | Read-only access — view research, attend sessions, and browse the repository. Cannot create or manage studies, and cannot own or moderate a study even at the study level. | | **Deactivated** | — | No access. Applied automatically when a member is removed from the workspace. | ## What admins can configure Admins control access across the workspace from **Settings > Governance**, across a few different areas: **Workspace Access** controls automatic entry for people from your company's email domain, when enabled, anyone with a matching email address joins as an Observer without an invite. You can enable this setting under [Permissions](https://greatquestion.co/governance/permissions). **Data Visibility** is actually three separate controls, not one setting: * Who can see candidates, studies, and repository artifacts at all — every workspace member, or only Admins and members of the affiliated team. * Which roles can see candidates' PII (personally identifiable information). * How calendar events tied to research appear to teammates in your connected calendar (Google, Outlook, and so on) — follow your calendar provider's normal defaults, always show full details, or always keep them private. **Default Sharing** sets the default visibility — Restricted or Public — separately for each artifact type: Interviews, Highlights, Reels, and Insights. This is just the default for newly created artifacts; Admins and Creators can still override it on any individual artifact. See [Artifacts](/support/support/repository/sharing-great-question-artifacts) for how per-artifact sharing works. **Custom Attributes** controls who can create new attribute definitions, Admins only, or Admins and Creators. This single setting covers both candidate and study attributes; there's no separate, stricter threshold for attributes flagged as PII or Health Information. **Approvals** has its own tab under Governance. Turn on **Funding approval** or **Activation approval** — or both — to require Admin review before a study can be funded or activated. Admins are always exempt, so studies they create are funded or activated without review. On **Enterprise** plans, you can go further and configure exemptions: auto-approve funding below a set dollar amount, or exempt specific Creators from funding or activation approval entirely. A separate **Approval request routing** setting on the same tab decides who any approval request goes to — the account owner, an Admin the requester nominates, or all Admins — and it applies to role-change requests too (see [Requesting a role change](#requesting-a-role-change) below). **Tag Management** controls who can create and manage tags — Admins only by default, or Admins and Creators. See [Tags](/support/support/repository/managing-tags) for how tagging works day to day. **Feature Access** lets Admins restrict specific actions to a narrower set of roles than usual, grouped by area, candidate operations (like importing or exporting candidates), study types you're allowed to create, study settings (like livestreaming or incentive automation), and repository features. Each toggle can be set to all roles, Admins and Creators, Admins only, or no one at all. ## Updating a member's role Only Admins can change roles. To update someone's role: 1. Go to **Settings > Members**. 2. Click the pencil icon next to the member you want to update. 3. Select the new role and save. A role change can be blocked if your account is out of seats for the target role, if the member owns active studies, or if they're the account's only Admin. There's no one-click ownership transfer today, to hand off sole-Admin ownership, promote someone else to Admin first, then change your own role. ### Requesting a role change Members don't have to wait for an Admin to notice they need more access. Trying to do something above your current role — like creating a study as an Observer — surfaces a **Request upgrade** option that opens a request for **Creator** or **Admin** access, with a default message you can edit before sending. The request goes to whoever your account's **Approval request routing** setting designates (see **Approvals** above): the account owner, a specific Admin, or all Admins. Whoever receives it sees it under **Approval requests** and can approve or decline it from there. Study-level roles are separate from workspace roles. On an individual study, people can be added as an **observer**, **moderator**, or **collaborator** to control who runs sessions and who can view results. An account-level Observer can be added at the study level too, but can't be made a study owner or moderator. ## Troubleshooting | Issue | What's happening | How to fix | | -------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------ | --------------------------------------------------------------------------------------------------------------------------- | | I can't assign someone the Creator role | Your account may be out of paid seats for that role | Free up a seat by changing another member's role, or add a seat under Settings > Billing | | I need to hand off Admin ownership before leaving | There's no built-in "transfer ownership" action | Promote the new person to Admin first, then change your own role afterward | | An invited Observer can't join a live observer room yet | They're still in **Pending** status until they accept their invite | Ask them to accept the invitation email, or resend it from Settings > Members | | Sharing a study's observer link externally isn't working as expected | Observer access via a shared study link is separate from adding someone as a workspace Observer | Use the study's dedicated observer link for external stakeholders rather than adding them as a workspace member | | My role change request is stuck pending | It's waiting on whoever your Approval request routing setting designates — the account owner, a nominated Admin, or all Admins | Check with that person directly, or an Admin can change your role from Settings > Members instead of waiting on the request | *** **Still need help?** Contact us at [support@greatquestion.co](mailto:support@greatquestion.co) — median response time is 19 minutes during [support hours](https://greatquestion.co/features/about-our-support-team).