Collaboration & admin
Roles & permissions
GoPie's permission model has two independent axes. Understanding them separately prevents nearly every "why can't I…" moment:
| Axis | Roles | What it controls |
|---|---|---|
| Organisation role | Owner · Admin · Member | Everything you do with data — creating, editing, deleting and sharing projects, datasets and the rest, inside one organisation |
| System role | System Admin · User | Exactly one thing: access to the admin console that manages users and organisations platform-wide |
The two never mix. A System Admin whose organisation role is Member can run the whole platform's user management — and still can't create a project in their own organisation. Your organisation role can also differ per organisation: owner of one, member of another.
The organisation-role matrix#
| Can they… | Owner | Admin | Member |
|---|---|---|---|
| See every project & dataset in the org | ✓ | ✓ | Only granted ones |
| Create projects & datasets | ✓ | ✓ | — |
| Edit projects & datasets | ✓ | ✓ | — |
| Delete projects & datasets | Any | Only their own | — |
| Refresh datasets from sources | ✓ | ✓ | — |
| Delete database source connections | ✓ | ✓ | — |
| Grant & revoke access (sharing) | ✓ | ✓ | — |
| Manage applications & API keys | ✓ | ✓ | — |
| Invite members, change roles, rename/delete the org | ✓ | — | — |
Two rules cut across the matrix:
- The creator override. Whatever your role, you keep full edit and delete rights on things you created. That's what "Only their own" means for admins — and it extends to members for the analysis artifacts below.
- Fail closed. Any unrecognised role is treated as Member — read-only, never more.
What members actually see#
Members don't get a read-only view of everything — they see only:
- projects and datasets they created, and
- projects and datasets explicitly granted to them by an owner or admin (see Sharing & access).
Everything else simply doesn't appear in their lists. A brand-new member's GoPie is empty until someone grants them a project.
Analysis artifacts follow the data#
Chats, saved views, dashboards and reports aren't role-gated the way projects are — they follow your access to the underlying data:
- Anyone who can open a dataset can chat with it, query it, and generate from it — including members, on their granted datasets.
- Chats are personal: only the creator sees a chat (unless it's shared with a public link) — even owners don't browse other people's chats.
- Dashboards and reports are visible to whoever can reach their source data. Editing one is for owners, admins, and its creator; everyone else gets a read-only canvas — the edit controls just don't appear.
The system-role axis#
The system role lives on the user, not on any organisation membership. System Admins see an Admin entry in their account menu and can manage every user and organisation on the deployment — create users, ban accounts, impersonate, reassign roles. Everyone else is a User and never sees that console. The full tour is in The admin console.
TipWhen someone reports "I can't edit this," check both axes in order: what's their organisation role here, and did they create the thing? System Admin status is never the answer to a data-access question.