Skip to main content
This page explains the lifecycle of a working session, how changes accumulate before a save, what happens during and after the save operation, and why this design matters for data integrity in regulated industries.

​
What Is a Working Session?

A working session begins the moment Risksheet loads data into the browser grid and ends when you navigate away from the page or close your browser tab. During a working session, every edit you make — changing a severity rating, adding a mitigation task, modifying a description — accumulates in the browser’s memory. These changes are not immediately written to Polarion. Think of a working session like a draft document in an email client. You compose your message (make edits to cells), and nothing is sent to the recipient (Polarion server) until you press the Send button (Save). Until that point, your draft exists only in your browser. diagram

​
Why Batch Saves Instead of Auto-Save

A natural question is: why not save every cell change immediately? Risksheet uses a batch save model for several important reasons tied to the domain of risk management in regulated industries: Transactional consistency. In an FMEA analysis, a single logical change often involves multiple cells. For example, updating a failure mode might require changing the severity rating, the occurrence rating, and the detection rating simultaneously. The RPN formula depends on all three values. Saving each change individually would create intermediate states where the RPN is inconsistent with the ratings, which could trigger incorrect conditional formatting or confuse concurrent viewers. Performance. Each save operation requires a server round-trip to update one or more Polarion work items. In a risk analysis with 200+ risk items, auto-saving every keystroke would create an unacceptable volume of server requests. Undo capability. The batch save model allows you to undo changes before they are committed. If you realize you made an error, you can revert individual cells or all changes before saving. Audit trail clarity. In ISO 26262, ISO 14971, and other safety standards, the audit trail of changes must be meaningful. A single save operation that captures a coherent set of changes (e.g., “Updated severity ratings after design review”) produces a cleaner revision history than hundreds of auto-saved micro-changes.
While batch saving provides consistency benefits, it also means unsaved changes exist only in your browser. If your browser crashes, network connection drops, or session times out, unsaved changes are lost. Save your work regularly to minimize the risk of data loss.

​
The Save Operation

When you trigger a save (via the toolbar Save button or keyboard shortcut), Risksheet performs the following sequence:
  1. Collect modified items. The grid identifies all work items whose fields have been modified since the last save (or since the session began).
  2. Validate changes. Basic validation runs client-side to check for required fields and type constraints.
  3. Send batch update. The modified work item field values are sent to the server as a batch operation.
  4. Server-side processing. The Polarion server validates the changes against workflow rules, field permissions, and data integrity constraints. Work items are updated in a transaction.
  5. Response and refresh. The server responds with the updated work item data. The grid refreshes to reflect any server-side transformations (e.g., workflow state changes, auto-calculated fields, timestamp updates).
diagram
If the server rejects any changes (due to permission violations, workflow constraints, or concurrent modifications), the save operation may partially fail. The grid will display an error indicator, and the affected cells will retain their unsaved values. See Save Operation Failures for resolution steps.

​
Unsaved Changes Tracking

During a working session, Risksheet tracks which cells have been modified but not yet saved. This tracking is essential for:
  • Visual indicators. Modified cells may display visual cues (such as a subtle change indicator) so you can see which values have changed.
  • Navigation warnings. If you attempt to navigate away from the page with unsaved changes, the browser will display a confirmation dialog asking if you want to leave without saving.
  • Selective save. The save operation only transmits modified work items, not the entire grid. This makes saves efficient even in large risk analyses.

​
Concurrent Editing

Risksheet does not implement real-time collaborative editing (like Google Sheets). Multiple users can open the same Risksheet document simultaneously, but they each work within their own independent session with their own unsaved changes.
ScenarioBehavior
Two users edit different risk itemsBoth saves succeed independently
Two users edit the same risk item, different fieldsLast save wins for each field
Two users edit the same field on the same risk itemLast save wins; first user’s change is overwritten
User A saves while User B has unsaved changes to the same itemUser B’s next save may overwrite User A’s changes
Risksheet does not detect or warn about concurrent edits to the same work item. In team environments, coordinate editing responsibilities to avoid overwriting each other’s work. Consider using the review workflow to formalize the editing process.
The lack of real-time conflict detection is a deliberate trade-off. In most FMEA and HARA workflows, risk analysis is performed by a single engineer or a small team working in sequence (not simultaneously), and the review process provides the coordination layer.

​
Session Timeout

Polarion sessions have a server-side timeout. If you leave a Risksheet document open without interaction for an extended period, your session may expire. When this happens:
  • Save operations will fail with a session timeout error.
  • You will need to reload the page, which establishes a new session.
  • Any unsaved changes at the time of timeout are lost.
The exact session timeout duration depends on your Polarion server configuration and is not controlled by Risksheet. Consult your Polarion administrator for the configured timeout value.
See Session Timeout Errors for troubleshooting guidance.

​
Read-Only Sessions

Not all working sessions allow editing. Risksheet enters a read-only session under the following conditions:
  • Historical revision. You are viewing a baseline or historical revision of the document. The revision parameter is non-empty, and the grid is automatically set to read-only.
  • Configuration override. The readonly property in risksheet.json is set to true.
  • Insufficient permissions. The current user does not have edit permission on the work items in the document.
  • Reviewer mode. The reviewer property is enabled, restricting the session to review-specific interactions.
In a read-only session, cell editing is disabled, item creation controls are hidden, and the save operation is unavailable. Formula columns and cell decorators still function normally, as they only affect the display.

​
Session State and Configuration

The working session also holds the active configuration state:
  • Active view. If saved views are configured, the currently selected view determines which columns are visible. Switching views during a session does not affect unsaved data — it only changes column visibility.
  • Sort order. The current sort order (defined by sortBy or user-initiated column sorting) persists within the session.
  • Filter state. Active column filters narrow the visible rows but do not affect which items are saved. A save operation writes back all modified items, including those hidden by filters.
If you filter the grid to show only high-severity items, then save, all modified items are saved — not just the filtered ones. Filtering is a display-only operation that does not affect the save scope.

​
Working Sessions and the Data Model

A working session operates on the data model described in Data Model and Work Items. Each row in the grid corresponds to a Polarion work item. The session maintains a local copy of each work item’s field values, and the save operation writes back only the fields that have been modified. The hierarchical structure (levels) defined in the configuration also plays a role in sessions. When you create a new risk item or task within the grid, the session must determine:
  • Which work item type to create (from dataTypes configuration).
  • Which document to create it in (from the createInDocument property or the current document).
  • Which link role to use for establishing relationships (from the role property in dataTypes).
These decisions are all governed by configuration and happen transparently during the working session.

​
Mental Model: The Editing Sandbox

The most useful mental model for working sessions is a sandbox. When you load Risksheet, you get a sandbox copy of the data in your browser. You can freely modify values, recalculate formulas, and see the effects of your changes in real time — all within the sandbox. Nothing touches the permanent Polarion data until you explicitly save. This sandbox model gives you the freedom to experiment. You can change a severity rating to see how it affects the RPN, then change it back before saving. You can add a new mitigation task to evaluate its effect on the risk matrix, then decide not to save it. The sandbox is yours to work with until you commit your changes.