This page explains how Polarion’s native permission layers interact with Powersheet’s configuration and runtime behavior, and where administrators should focus their attention when setting up role-based access.
The Permission Inheritance Principle
Think of Powersheet as a window into Polarion data. Just as a glass window lets you see what is on the other side but does not change what is actually there, Powersheet displays and edits work items through Polarion’s own data layer. The permissions governing who can see and modify those work items are determined by Polarion, not by Powersheet itself.
This means:
- A user who cannot read a certain work item type in Polarion will not see those items in a Powersheet view
- A user who lacks write permission on a field in Polarion will be unable to save changes to that field through the sheet
- Project-level role assignments in Polarion carry directly into what a user experiences in Powersheet
Powersheet does not maintain its own user database or authentication system. Users are authenticated by Polarion, and their identity flows through to every Powersheet operation.
Polarion’s Role-Based Access Control
Polarion uses a role-based access control (RBAC) system with two layers: global roles and project roles. Both layers affect what a user can do inside Powersheet.
Global Roles
Global roles apply across the entire Polarion instance. The most relevant global roles for Powersheet are:
| Global Role | Powersheet Impact |
|---|
| Administrator | Full access to all projects and configurations, including domain model and sheet configuration YAML files |
| User | Standard access governed by project-level role assignments |
| Guest / External | Typically read-only; cannot save changes through the sheet |
Project Roles
Within each Polarion project, users are assigned one or more project-level roles. These roles determine fine-grained permissions on work item types, fields, and operations.
Common project roles that affect Powersheet behavior:
| Project Role | Typical Permissions | Powersheet Effect |
|---|
| Project Admin | Full project control | Can modify domain models, sheet configurations, and all data |
| Project Member | Read/write on most work items | Can view and edit sheet data within their permission scope |
| Reviewer | Read-only on documents and items | Can view sheets but not save changes |
| External Stakeholder | Limited read access | May see only certain entity types in the sheet |
A user who is a Project Admin in one project may be a Reviewer in another. Powersheet respects this boundary — the same user will have full editing capabilities in the first project’s sheets and read-only access in the second.
How Permissions Affect Sheet Operations
Powersheet operations map to Polarion permission checks at several levels. Understanding these mappings helps explain why a user might be able to perform some actions in a sheet but not others.
Viewing Data
When a sheet loads, Powersheet queries Polarion for work items matching the sheet’s source configuration and expansion paths. Polarion’s query engine automatically filters results based on the current user’s read permissions. If a user lacks read access to a particular work item type (for example, Hazard items in a safety project), those rows simply will not appear in the sheet.
This filtering is transparent — the sheet displays only what the user is authorized to see, without error messages for items that were filtered out.
Editing and Saving
When a user modifies a cell and triggers a save operation, Powersheet sends the change to Polarion’s server API. Polarion validates that the current user has write permission on the specific field of the specific work item being modified. If the user lacks permission, the save operation will be rejected.
Key behaviors during save:
- Field-level granularity: A user might be able to edit the
severity field on a Hazard but not the status field, depending on workflow and field-level permissions
- Workflow constraints: Even with write permission, Polarion workflow rules may prevent certain state transitions
- Link role permissions: Creating or removing links between entity types (for example, linking a
RiskControl to a Hazard) requires permission on both the source and target work items, as well as permission to modify the relevant link role
For more details on how save operations are processed, see Save Operations Guides.
Configuration Access
Modifying domain model YAML files and sheet configuration YAML files is an administrative action. These files are stored in the project’s SVN repository under the .polarion/nextedy/ directory structure.
Access to configuration requires:
- SVN write access to the project’s configuration directory
- Project administration privileges in Polarion, typically granted through the Project Admin role
- Access to the Administration > Nextedy POWERSHEET menu in the Polarion UI
Unlike data edits that affect individual work items, changes to domain models and sheet configurations affect every user who opens that sheet. Always coordinate configuration changes with your team.
License State Override
Before any role-based permission check applies, Powersheet evaluates the license state of the Nextedy POWERSHEET installation. The license state acts as a global override layer that sits above all roles and project permissions.
| License State | Effect |
|---|
| Valid | Normal operation — role-based permissions apply as described below |
| Invalid / Expired | Global read-only mode — all users, including administrators, lose write access. Sheets can be viewed but no data can be saved or modified. |
An expired or invalid license forces every user into read-only mode. If users report that save operations are failing across all projects simultaneously, check the license state before investigating role assignments.
The Three Permission Tiers
In practice, Powersheet users fall into three broad permission tiers based on how Polarion’s RBAC maps to sheet functionality.
Tier 1 — Viewer
Users with read-only project access. They can:
- Open sheets and browse entity hierarchies through expansion paths
- Switch between named views to see different column presets
- Sort, filter, and search within their visible data
- Export visible data where export functionality is available
They cannot modify any data or configuration.
Tier 2 — Editor
Users with project write access on relevant work item types and fields. They can do everything a Viewer can, plus:
- Edit cell values directly in the sheet
- Save changes to work item fields they have write permission on
- Create, modify, or remove links between entity types (subject to link role permissions)
- Trigger workflow transitions where their role permits
Tier 3 — Administrator
Users with project administration privileges. They can do everything an Editor can, plus:
- Modify domain model YAML files (entity types, relationships, cardinality)
- Create and modify sheet configuration YAML files (columns, formatters, binding paths)
- Manage views (named column visibility presets)
- Configure process constraints and validation rules
For guidance on administrative tasks, see Administration Guides.
Views and Permission Boundaries
Views in Powersheet — named column visibility presets that allow different analysis perspectives — are available to all users who can access the sheet. Views do not add or restrict data access; they simply control which columns are visible in the current layout.
This is an important distinction: a view labeled “Safety Analysis” that shows risk-related columns does not grant access to risk data that the user could not already see. If a user lacks read permission on Hazard entity types, those columns will be empty regardless of the view selected.
For more on how views work, see Views as Analysis Perspectives.
Common Misconceptions
”Powersheet has its own permission system”
Powersheet does not maintain a separate permission layer. Every access check is delegated to Polarion. If a user reports unexpected access restrictions in a sheet, the investigation should start in Polarion’s project role and permission configuration, not in Powersheet’s YAML files.
”Hiding a column hides the data”
Removing a column from a sheet configuration or a view makes the data invisible in that particular sheet layout, but it does not restrict access to the underlying work item field. Users can still see and edit that field through Polarion’s native work item editor, other sheets, or the Polarion API. Column visibility is a presentation concern, not a security mechanism.
”Domain model restrictions limit data access”
The domain model defines which entity types and relationships Powersheet knows about and can navigate. If an entity type is not in the domain model, Powersheet will not display it — but this is a configuration scope decision, not an access control mechanism. The underlying data remains accessible through Polarion’s standard interfaces.
The exact behavior of permission enforcement during save operations, including error messaging and partial-save handling, may vary by Polarion version and Powersheet release. Test your specific permission configurations in a non-production environment before rolling out to users.
Practical Implications for Configuration
When designing sheet configurations, keep these permission-related principles in mind:
Match sheet scope to audience roles. If a sheet is intended for reviewers who have read-only access, avoid including editable columns that will produce save errors. Instead, consider creating separate sheet configurations for different permission tiers — a read-oriented view for reviewers and an edit-oriented configuration for project members.
Use Polarion’s field-level permissions for sensitive data. If certain fields (for example, cost estimates or proprietary risk assessments) should be visible only to specific roles, configure those restrictions in Polarion’s permission settings rather than relying on column visibility in Powersheet.
Test with representative user accounts. When setting up a new sheet configuration, log in as users with different project roles to verify that the sheet behaves correctly at each permission level. Pay particular attention to save operations and link creation, where permission gaps are most likely to surface.
Document role requirements. For each sheet configuration you deploy, maintain a note of which Polarion project roles are expected to use it and whether they need read-only or read-write access. This helps onboarding and troubleshooting.
For step-by-step configuration guidance, see Sheet Configuration Guides and Data Model Guides.
Relationship to Process Constraints
Powersheet’s process constraints (validation rules that enforce data quality during save operations) operate alongside Polarion’s permissions but serve a different purpose. Permissions answer “is this user allowed to modify this field?” while constraints answer “is the proposed value acceptable?”
A user might have full write permission on a field but still be prevented from saving by a constraint that enforces a required value or a specific format. These two mechanisms are complementary — permissions gate who can act, and constraints gate what actions are valid.
For more on how constraints work, see Process Constraints.
Summary
Powersheet’s permission model is deliberately simple: it defers entirely to Polarion’s role-based access control. This design means there is no separate permission system to learn, configure, or maintain. The trade-off is that effective Powersheet access management requires a solid understanding of Polarion’s project roles, field-level permissions, and workflow rules — the same skills needed to administer any Polarion project.
| Concern | Where to Configure |
|---|
| Who can see which work items | Polarion project roles and work item type permissions |
| Who can edit which fields | Polarion field-level permissions and workflow rules |
| Who can modify sheet configuration | Polarion project administration role + SVN access |
| Which columns appear in the sheet | Sheet configuration YAML and views |
| What values are valid during save | Process constraints in Powersheet configuration |
