User permissions can be configured at different layers:
- Peliqan UI
- Data warehouse layer
- BI layer
- Data app layer
- API Endpoint layer
Permissions in the Peliqan UI
Groups
The Peliqan UI user permission model is based on groups.
You can manage Users and Groups in Peliqan under Admin.
Users can be added as member to multiple groups. Users have a role within each group. Available group roles:
- Admin:
- Can access and edit resources in the group (schemas, connections, data apps etc.)
- Can invite new users to group (this will create a new user and make them member of the group)
- Can change role of users within group
- Member:
- Can access and edit resources in the group (schemas, connections, data apps etc.)
- Viewer:
- Has read-only access to resources in the group
Following resources can be added to a group (resources can only belong to one group):
- Schemas (collection of tables within a DB or DWH)
- ELT Connections
- Data apps
Users have access to the resources in the groups for which they are a member. If a user has access to a schema, the user also has access to all tables/queries in that schema. Note that permissions cannot be set on the DB level or table level, only at the schema level.
Note that labels can be used to organize resources in Peliqan, but labels are not used for permissions.
Account owners
Account owners have access to following features in Peliqan:
- Get API key of the account
- Create users
- Invite users
- Create new groups
- Add users to groups
- Edit users
Permission matrix
Resource/Operation | ACCOUNT OWNER | GROUP ADMIN | GROUP MEMBER | GROUP VIEWER |
Group Management | ||||
Edit Group Name | ✅ | ✅ | ❌ | ❌ |
Edit Group Users (Members) | ✅ | ✅ | ❌ | ❌ |
Invite New Users
(creates new user + adds to group as member) | ✅ | ✅ | ❌ | ❌ |
Remove Group Users | ✅ | ✅ | ❌ | ❌ |
Create Group | ✅ | ❌ | ❌ | ❌ |
Delete Group | ✅ | ❌ | ❌ | ❌ |
Connections | ||||
View Connection | ✅ | ✅ | ✅ | ✅ |
Create Connection | ✅ | ✅ | ✅ | ❌ |
Update Connection | ✅ | ✅ | ✅ | ❌ |
Delete Connection | ✅ | ✅ | ✅ | ❌ |
Data Apps | ||||
View Data App Source Code | ✅ | ✅ | ✅ | ✅ |
Run Data App | ✅ | ✅ | ✅ | ✅ |
Create Data App | ✅ | ✅ | ✅ | ❌ |
Update Data App (edit source code) | ✅ | ✅ | ✅ | ❌ |
Publish Data App | ✅ | ✅ | ✅ | ❌ |
Delete Data App | ✅ | ✅ | ❌ | ❌ |
Viewing a Published Data App (depends on publish settings) | ||||
API Endpoints | ||||
View API Endpoint | ✅ | ✅ | ✅ | ✅ |
Create API Endpoint | ✅ | ✅ | ✅ | ❌ |
Update API Endpoint | ✅ | ✅ | ✅ | ❌ |
Delete API Endpoint | ✅ | ✅ | ✅ | ❌ |
Call API Endpoints: depends on setting (e.g. JWT token, public access, custom API key in source code) | ||||
Schemas | ||||
View Schema | ✅ | ✅ | ✅ | ✅ |
Create Schema | ✅ | ✅ | ✅ | ❌ |
Update Schema | ✅ | ✅ | ✅ | ❌ |
Delete Schema | ✅ | ✅ | ✅ | ❌ |
Tables (based on schema) | ||||
View Table Data | ✅ | ✅ | ✅ | ✅ |
Create Table | ✅ | ✅ | ✅ | ❌ |
Update Table | ✅ | ✅ | ✅ | ❌ |
Delete Table | ✅ | ✅ | ✅ | ❌ |
Views/Queries (based on schema) | ||||
See View Data | ✅ | ✅ | ✅ | ✅ |
Create View | ✅ | ✅ | ✅ | ❌ |
Update View | ✅ | ✅ | ✅ | ❌ |
Delete View | ✅ | ✅ | ✅ | ❌ |
Rows (based on schema of table) | ||||
View Row | ✅ | ✅ | ✅ | ✅ |
Create Row | ✅ | ✅ | ✅ | ❌ |
Update Row | ✅ | ✅ | ✅ | ❌ |
Delete Row | ✅ | ✅ | ✅ | ❌ |
Fields (Columns) | ||||
View Field | ✅ | ✅ | ✅ | ✅ |
Create Field | ✅ | ✅ | ✅ | ❌ |
Update Field | ✅ | ✅ | ✅ | ❌ |
Delete Field | ✅ | ✅ | ✅ | ❌ |
Webhooks | ||||
View Webhook URL | ✅ | ✅ | ✅ | ✅ |
API Token (JWT at account level) | ||||
View Token | ✅ | ✅ | ✅ | ✅ |
Create Token | ✅ | ✅ | ✅ | ❌ |
Rotate Token | ✅ | ✅ | ✅ | ❌ |
Delete Token | ✅ | ✅ | ✅ | ❌ |
Direct Queries | ||||
Execute Direct Query | ✅ | ✅ | ✅ | ❌ |
Peliqan accounts & sub-accounts
Access to data and other resources, can also be managed by using separate Peliqan accounts and sharing data between accounts.
For example, Partner accounts in Peliqan can create sub-accounts per end-customer.
Sub-accounts can also be used to provide controlled access to individual teams, divisions or other groups of users.
Customers with Enterprise licences can contact Peliqan Support, to request the setup of a separate Peliqan account for testing (dev), staging and production.
More info on sharing data between Peliqan accounts:
Sync data between parent & sub accountsPermissions in the data warehouse layer
You can create separate users in the data warehouse for controlled access to datasets in your data warehouse. This is useful to enforce access control at the data warehouse level, so that it also applies to any data consumer connected to the DWH (e.g. a BI tool).
- Peliqan built-in data warehouse: contact Peliqan Support
- External data warehouse (Bigquery, Snowflake etc.): configure users in the UI of your data warehouse
Permissions in the BI layer
Data access control is often implemented in the BI layer, so that individual users can access the data they are entitled to see in dashboards and reports.
It’s common to configure “Row Level Access” (or Row Level Security, RLS) in BI tools, which filters data in dashboards and datasets, based on the role of the current user. This is often combined with SSO (Single Sign On) using e.g. Microsoft Entra ID, so that Row Level Access can be applied based on the groups to which the user belongs in Entra.
More info:
Permissions in the Data App layer
Data Apps are interactive apps, built in Peliqan using low-code Python. Data Apps can be used inside Peliqan, and they can be published or embedded for external access.
User permissions (including SSO) can be added in the source code of Data Apps.
More info:
Adding a login to your appPermissions in the API Endpoint layer
In Peliqan you can publish API endpoints, e.g. to share data with external partners.
Permissions can be implemented in the source code API handler of each API endpoint.
More info:
Publish APIs