The Three Usage Tiers
In any risksheet — whether it is a Failure Mode and Effects Analysis (FMEA), a Hazard Analysis and Risk Assessment (HARA), a Threat Analysis and Risk Assessment (TARA), or a generic compliance traceability matrix — people interact with the grid in one of three ways. These tiers describe what a person does, not what role Polarion has assigned to them. The Polarion role and the active licenses then determine whether that activity is actually permitted.
Tier 1: Viewer / Reviewer
The Viewer/Reviewer tier treats a risksheet as an interactive report. People at this tier open the document, scroll through risk items, switch between saved views (for example, “Classification Summary” versus “Final Risk Assessment”), filter and sort the grid, drill into linked requirements or test cases, and export the result to Excel or PDF. They can also participate in review workflows — leaving comments, voting on approval-tagged items, or marking review work items — without changing the underlying risk data. This tier is the right fit for stakeholders who consume risk analysis as evidence rather than producing it: auditors checking ISO 26262 work products, project managers tracking Risk Priority Numbers (RPNs) before a milestone, customers reviewing a HARA, or compliance officers verifying ISO 14971 risk control coverage.Tier 2: Author
The Author tier is for the people who build the risk analysis itself. Authors create new risk items, edit field values (severity, occurrence, detection, hazard classification, treatment, residual risk), attach mitigation tasks through link columns, recalculate formulas, and toggle between saved views to focus on a particular phase of the analysis. Authors typically include safety engineers running an FMEA, hazard analysts producing a HARA, cybersecurity analysts building a TARA or STRIDE table, and quality engineers driving a Common Vulnerability Scoring System (CVSS) workflow. An Author still operates within the structure that an Administrator has defined. They do not change which columns exist, which work item types are used for risk items versus mitigation tasks, or which formulas calculate the risk score — they fill in the analysis under that structure.Tier 3: Administrator
The Administrator tier configures the structure that Authors work inside. Administrators choose the work item types backing risk items and mitigation tasks (dataTypes.risk.type, dataTypes.task.type), define the visual hierarchy through the levels array, decide which columns appear and what they map to with the bindings property, attach formulas and cell decorators, edit the top panel template that hosts risk matrices and dashboards, and publish templates that other projects inherit.
Administrators also set Risksheet’s project properties (template paths, suggester behavior, permission flags), control which user views see the Risksheet topic in Polarion navigation, and decide which projects use which licenses.
A single person can move between tiers depending on the document. A safety engineer might be an Author on the system FMEA they own, a Reviewer on a peer’s HARA, and only a Viewer on a TARA owned by the security team. The combination of Polarion permissions and license assignment determines whether each activity is actually allowed.
The License Model
Risksheet’s license model maps onto the three usage tiers. There are two license types, and the way they combine is what creates the practical distinction between “can change risk data” and “can read risk data”.
The Connect license is server-wide: once it is active on the Polarion server, anyone with a Polarion seat and the necessary project access can open a risksheet in read-only mode. This is what lets large organizations expose risk analyses to stakeholders, auditors, and reviewers without buying a per-user Risksheet seat for every observer.
The Author license is named and per-user — assigned to specific people who actually build and maintain the risk analysis. Authors and Administrators both need it. Without it, even a Polarion Project Administrator sees the risksheet as read-only.
How Polarion Permissions Layer In
Because every risksheet cell is a Polarion work item field, Polarion’s permission system applies to every read and every save. This is intentional: it means a risk analysis enjoys the same audit trail, access control, and traceability infrastructure as the requirements, test cases, and design items it links to. Polarion permission concepts that directly affect a risksheet user:
A common surprise: a user might have an Author license and a Project User role, but still see a particular column as read-only. The cause is almost always at the Polarion layer — a workflow has moved the item to a state where the field is locked, or the field is restricted to a different role by Polarion’s permission management.
Polarion’s “Read-only Fields” project property is a UI-only setting that has no programmatic interface. Risksheet cannot read it directly, so this property alone does not enforce field-level restrictions in the grid. To enforce read-only behavior based on work item status, use Risksheet’s Permissions Management with the
nextedy.risksheet.checkInstanceFieldPermissions=true project property. Risksheet then evaluates the same workflow-state field permissions that Polarion uses elsewhere.Project Properties That Shape Permissions
A handful of project administration properties (set under Administration > Nextedy Risksheet > Setup) directly affect what a user can do. These are not user roles themselves — they are switches that an Administrator flips to extend or restrict how Risksheet interprets Polarion permissions. The defaults are listed where verified in the product knowledge base.
The interaction matters: switching on
checkInstanceFieldPermissions is the recommended way to make a risksheet honor workflow-state field locks. Without it, a user with the Author license who otherwise has edit rights on the work item may be able to change a field that the workflow intends to freeze.
Visibility: The Topic Gate Before Permissions
A subtle but frequent source of “I cannot access Risksheet” tickets is not permissions at all — it is navigation visibility. Risksheet appears in the Polarion sidebar through a Risksheet topic that is mapped to user views (also called “hats”). If the topic is missing from the active view, the user does not see Risksheet in the sidebar at all and is redirected to the project home page or the space home page when they try to navigate to it.
Reviewer Mode and Downstream Read-Only
Beyond the three core tiers, Risksheet supports two server-injected runtime modes that further constrain what a session can do — they are decided by Risksheet at load time, not chosen by the user:- Reviewer mode is enabled automatically when the user is participating in a review of the risksheet. The grid switches into a review-specific UI with annotation controls. The user can read every column, leave comments, and approve or reject — but cannot freely edit risk data outside the review workflow.
- Downstream read-only treats linked items from other documents as non-editable, even if the user has the Author license. This prevents accidental cross-document edits when an author opens a risksheet that includes upstream references to a shared harms library or requirements catalog.
A Shared Mental Model
A useful way to think about access to a risksheet is as a stack of filters that each user request passes through, in order:
The Author capability is granted only when every layer above it permits the action. This is why the most common ticket category — “I have a license but cannot edit field X” — almost always resolves at a layer other than licensing: the workflow has locked the state, the column is configured
readOnly: true, the field is upstream-bound, or the user is operating in a review.
Common Misconceptions
The following beliefs come up repeatedly in support tickets and are worth dispelling before they shape an access-control strategy.“Risksheet has its own user database, so I just need to grant the user a Risksheet role.”Risksheet does not maintain user accounts or roles. Users are Polarion users; their effective Risksheet capabilities come from Polarion permissions plus license entitlement.
“Polarion’s Read-only Fields setting will lock fields in the grid.”The Read-only Fields project setting is a UI-only Polarion property without an API, so Risksheet cannot enforce it. To make a field read-only based on workflow state, enable
nextedy.risksheet.checkInstanceFieldPermissions=true and use Polarion’s Permissions Management, which Risksheet does evaluate.
“If a Project Administrator opens a risksheet, they can edit everything.”A Project Administrator who lacks an Author license can still only view a risksheet. The Polarion role grants the administrative ability to change configuration if a license is present, but read-only is the default without one.
“Risksheet stopped working in Firefox after the update — must be a browser issue.”Usually the topic for Risksheet is missing from the user’s current view. The browser is fine; the navigation view simply does not surface Risksheet anymore, and the user is redirected.
“I can change the sheet configuration since I am an editor on the document.”Editing the sheet configuration requires a Polarion Admin role on the project. Document edit rights are not sufficient. Non-admin users who need configuration changes must coordinate with their project administrator.
Exact license names, project property defaults, and topic configuration paths may evolve between Risksheet releases. When in doubt, verify in your installed version under Administration > Nextedy Risksheet > Setup and Administration > Topics.
How This Connects to Other Concepts
User access is just one cross-cutting concern in a risksheet. To follow the related concepts:- For how risksheet data is structured and persisted as Polarion work items, see Data Model and Work Items.
- For the review workflows that drive Reviewer mode, see Review Workflows.
- Licensing walks through assigning and renewing Author and Connect licenses.
- Administration covers Risksheet project setup, including topic configuration and project properties.
- Configuration Management and Advanced Configuration show how Administrators publish and inherit templates.
- Review Management explains how to run comment-based, work-item-based, and approval reviews.
- Troubleshooting lists fixes for the visibility, license, and permission symptoms described here.