This page explains the conceptual model behind these layers, why they exist, and the common misconceptions teams hit when granting access for FMEA, HARA, TARA, STRIDE, or compliance traceability work.
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”.
| License | Scope | Grants | Typical Tier |
|---|
| Author license | Named, per user | Create, edit, and delete risk items, mitigation tasks, formulas, and saved views | Author, Administrator |
| Connect license | Server-wide | Open and view risksheets, run saved views, export, comment, participate in reviews | Viewer / Reviewer |
Licenses control whether a Risksheet feature is available at all. Polarion’s project permissions control whether a specific user is allowed to use it on a specific document. A user with an Author license still cannot edit a risksheet in a project where Polarion grants them only read access. Risksheet never bypasses the underlying authorization model — it inherits it.
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:
| Polarion concept | What it controls in Risksheet |
|---|
| Project role assignment | Whether the user can open documents in this project and edit work items at all |
| Work item permissions (per type, per role) | Whether specific fields on the underlying risk or task work items can be edited |
| Workflow state | A risk item in an approved state may be locked by its workflow even if the user has the Author license |
| Document workflow | A LiveDoc in a frozen state prevents structural changes through the risksheet |
| User group / hat | Which navigation topics — and therefore which risksheets — are even visible to the user |
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.
| Property | Default | Effect on permissions |
|---|
nextedy.risksheet.checkInstanceFieldPermissions | false | When true, Risksheet honors per-state field permissions defined by Polarion’s permission management — so a field becomes read-only in the grid when the work item’s current workflow state restricts it |
nextedy.risksheet.checkPrototypePermissions | true | Enforces work item type prototype permissions before allowing edits |
nextedy.risksheet.upstreamSubColumnsReadonly | true | Treats columns that display fields of linked upstream items (for example, a column with bindings: harm.title) as read-only |
nextedy.risksheet.editableReferencedWorkItems | false (v23.3.3+) | Project administration property allowing limited editing of referenced upstream work items directly from the grid |
nextedy.risksheet.moduleOnlyPermissions | false (v24.8.5+) | Constrains permission evaluation to document-scope only |
nextedy.risksheet.checkLinkRoleCompliance | false (v24.2.2+) | Validates link role compatibility before allowing relationship edits |
nextedy.risksheet.risksheetTemplatePath | Risks/Risk Specification | Restricts where Authors can create new risk documents from templates — multiple paths can be comma-separated |
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.
Visibility is gated before permissions are even evaluated. Several support tickets that initially looked like browser compatibility issues or installation failures turned out to be a missing topic in the user’s current view after an upgrade. The symptom is consistent: the user is silently redirected away from the Risksheet URL, sometimes with an unrelated error such as an XML parsing error on a stylesheet.
The correct fix is in Administration > Topics: ensure that every view used by people who need access to risksheets includes the Risksheet topic. This is an administration task, not a permission change.
Before suspecting browser compatibility, certificates, or licensing, check that the user’s current view still includes the Risksheet topic. Custom views built for niche roles often omit topics added by later releases.
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.
These modes are part of why a user with the Author license still sees a “read-only” experience on a particular sheet. The cause is the document’s review state or its linkage to upstream libraries, not a permission misconfiguration.
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:
| Layer | Decided by | Result |
|---|
| 1. Visibility (topic in view) | Administrator (Topics configuration) | Can the user see Risksheet at all? |
| 2. License (Connect or Author) | Server-wide license configuration | View only, or view + edit? |
| 3. Polarion project role | Polarion administration | Which projects and documents are accessible? |
| 4. Work item / workflow permissions | Polarion administration + Risksheet project properties | Which fields can change in which states? |
| 5. Risksheet runtime mode | Risksheet (review state, downstream linkage) | Reviewer mode, downstream read-only? |
| 6. Configuration intent | Administrator (sheet configuration) | Which columns are marked readOnly: true in the configuration? |
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 the practical tasks behind these concepts, the following how-to guides cover the steps that an Administrator or Author actually performs:
Across all of these, the central principle remains the same: Risksheet visualizes and edits Polarion data — it does not store data separately, and it does not introduce a separate authorization layer. The right access for each user comes from choosing the appropriate usage tier, granting the right license, and letting Polarion’s project permissions do the work they were designed for.
