Data Hub permissions
Data Hub splits its permissions differently from most modules, because a connection is a platform object rather than a service one.
Two levels
Section titled “Two levels”Service membership covers everything you do with data that is already connected: browsing, previewing, exporting, enabling tables, building views, and mapping relationships.
The platform admin role is required to create, edit, or delete a data source.
The split follows from what a source is. Its credentials may reach a database that other services also use, so introducing one is a platform decision. Using what has been introduced is a service decision.
What each level allows
Section titled “What each level allows”| Operation | Needs |
|---|---|
| Open the workspace | Service membership |
| Browse connections and tables | Service membership |
| Preview rows, filter, and sort | Service membership |
| Export data | Service membership |
| Enable and disable tables | Service membership |
| Create, edit, and delete views | Service membership |
| Detect and commit relationships | Service membership |
| Change cache settings | Service membership |
| Use the Writeback Lab | Service membership |
| See the connector catalogue | Any signed-in user |
| Create a data source | Platform admin |
| Edit a data source | Platform admin |
| Delete a data source | Platform admin |
| List all platform sources | Platform admin |
Note where writeback sits. Any service member can write to a connected database through the Writeback Lab, subject only to what the connector allows and what the database credentials permit. That is worth knowing when deciding which credentials a connection should use — a read-only database user is the difference between a member being able to browse and being able to change production data.
The practical workflow
Section titled “The practical workflow”An administrator creates the connection once. Service members then link it if needed, choose their visible tables, build views, and query — without elevated access.
If you cannot create a connection but can see Link Existing entries in the wizard, that is this split, not a fault.
Membership, not roles
Section titled “Membership, not roles”Service access here is membership-based: being a member of the service, directly or through a team attached to it. There is no viewer-versus-editor distinction within Data Hub — a member who can open the workspace can also enable tables and build views.
Someone holding system_admin bypasses every check.
Table visibility is not a permission
Section titled “Table visibility is not a permission”Enabling a table exposes it to the service, and every member of that service can then read it. There is no per-member table permission.
So the visibility list is a service-wide decision. If some data should be visible to some members and not others, exposing it in a shared service will not achieve that — separate services on the same connection will.
Related
Section titled “Related”Connections and services explains why sources are shared. Choose which tables to expose covers the visibility decision.