Permission Sets
A Permission Set is a pre-defined collection of permissions that grants access to specific application features, screens, and operations. Permission Sets control:
- UI/Screen Access - Which pages and interfaces users can view
- Functional Operations - What actions users can perform (create, edit, delete)
- Administrative Functions - System configuration and management capabilities
Default Permission Sets
Promethium provides six out-of-the-box Permission Sets organized by functional area and user persona as examples. You can create permission sets that match your organization and roles.
Permission sets work together with Data Authorization to control data visibility in Promethium UIs. Users will see tables, views, and datamaps based on the Data Authorization rules applicable to their user and/or Role(s).
See Data Authorization for more details on fine-grained access control.
Example Administrative Permission Sets
tenant_admin
Full administrative control over user and access management functions.
Capabilities:
- User Management: Create, edit, delete, and view users
- Role Management: Create, edit, delete, and view roles; assign roles to users
- Permission Set Management: Create, edit, delete, and view permission sets
- Audit Logs: View audit logs for compliance and monitoring
Use Case: Platform administrators who manage user access, roles, and system configuration for the tenant.
data_admin
Comprehensive data platform administration and governance.
Capabilities:
- Data Exploration: View and edit tables, table data, tags, and endorsements.
- Data Sources: Create, view, edit, and delete data sources
- Domain Management: Create, view, edit, and delete domains
- Marketplace: View, publish, and approve marketplace content
- System Dashboard: View tables, data sources, executions, and recent answers
- Job Management: Schedule and manage data jobs
Use Case: Data platform owners, chief data officers, and data governance leads responsible for overall data platform operations.
Example Data Professional Permission Sets
data_engineer
Focused on Data Answer development and data asset creation.
Capabilities:
- Data Exploration: View and edit tables, table data, tags, and endorsements.
- Data Sources: View and edit data sources
- System Dashboard: View tables, data sources, executions, and recent answers
- Marketplace: View marketplace content
Use Case: Data engineers and analytics engineers who build and maintain data pipelines, datamaps, and analytical datasets.
data_steward
Data quality, metadata management, and marketplace governance focused.
Capabilities:
- Datamap Management: View, edit, and delete datamaps
- Data Exploration: View tables and table data, edit table metadata, tags, and endorsements.
- Data Sources: Create, edit, and delete data sources
- System Dashboard: View tables, data sources, executions, and recent answers
- Marketplace: View, publish, and approve marketplace content
Use Case: Data stewards responsible for data quality, metadata accuracy, data cataloging, and marketplace governance.
Example Business User Permission Sets
business_user
Read and explore capabilities for business analysts and consumers.
Capabilities:
- Datamap Management: View datamaps
- Data Exploration: View tables and table data, edit table metadata, tags, and endorsements.
- System Dashboard: View tables, data sources, executions, and recent answers
- Marketplace: View marketplace content
Use Case: Business analysts and end users who consume data and create basic analytical content.
data_explorer
Query and discovery focused permissions with enhanced access.
Capabilities:
- Datamap Management: View datamaps
- Data Exploration: View tables and table data, edit table metadata, tags, and endorsements
- Data Sources: View data sources
- System Dashboard: View tables, data sources, executions, and recent answers
- Marketplace: View marketplace content
Use Case: Data analysts who explore datasets and create queries for analysis.
Permission Types
Promethium permissions control UI features and functional capabilities. Object modification and data access are controlled by Access Levels (Owner, Editor, Viewer) through Data Authorization.
Permission Examples:
create_datamap- Grants ability to use the "Create Datamap" featureview_datasource- Grants ability to view the Data Sources tabcreate_datasource- Grants ability to add new data source connections
Note: Having create_datamap permission allows you to use the create feature, but you can only create Datamaps on domains/objects where you have appropriate access levels (Owner or Editor). Similarly, view permissions control UI access, while actual data visibility is determined by your access level grants through Data Authorization.
See Data Authorization for how Access Levels control object modification and data visibility.
Managing Permission Sets
Viewing Permission Sets
The Permission Sets section within Tenant Management displays all available permission sets in your tenant. Each permission set entry shows:
- Permission set name and description
- Number of individual permissions contained
- Associated roles that include this permission set
- Last modification timestamp
You can search and filter permission sets by name to quickly locate specific configurations.
Creating Custom Permission Sets
Administrators can create custom Permission Sets tailored to organizational needs. The permission set creation interface presents permissions in a hierarchical tree structure, organized by functional areas such as:
- access_data_explorer_functionality - Data browsing and exploration capabilities
- access_tenant_management_functionality - User and role administration
- access_datamap_functionality - Datamap lifecycle management
- access_datasource_functionality - Data source configuration
Permissions can be selected individually or by entire functional groups, allowing precise control over what capabilities the permission set grants.
Editing Permission Sets
Permission Sets can be modified to add or remove individual permissions. The edit interface shows the current permission structure and allows administrators to adjust the permission tree.
Changes to Permission Sets take effect immediately for all users and roles assigned to them.
Deleting Permission Sets
Permission Sets can be removed from the system if they are no longer needed.
Permission Sets that are currently assigned to one or more Roles cannot be deleted. The permission set must first be removed from all role configurations before deletion is permitted.
Best Practices
Design Principle
- Group related permissions - Keep functionally related permissions together
- Follow least privilege - Grant only necessary permissions
- Use descriptive names - Make Permission Set purpose clear
- Document custom sets - Maintain documentation for custom Permission Sets
Common Patterns
- Read-only roles - Combine view-only permissions for data consumers
- Power user roles - Combine create/edit permissions without delete
- Admin roles - Include administrative permissions for system management