Sessions vs. Polarion Data
Risksheet is a grid that visualizes and edits data living in Siemens Polarion ALM. There is no separate Risksheet database — every risk item, severity rating, mitigation link, and Risk Priority Number (RPN) value is stored as a standard Polarion work item with custom fields. A working session is simply the browser’s view of those work items at a point in time, plus any unsaved edits you have made since the grid was loaded.
Staged Work Across Multiple Days
Failure Mode and Effects Analysis (FMEA), Hazard Analysis and Risk Assessment (HARA), and Threat Analysis and Risk Assessment (TARA) analyses rarely complete in one sitting. A typical risk specification document evolves over weeks: identifying failure modes one day, classifying severity and occurrence in a workshop later, then revisiting mitigations after a design review. Each return to the document is a new working session — the grid loads the current state of every risk item from Polarion, including changes made by other team members in between. A few properties of this model matter in practice:- Closing the browser tab or navigating away discards any unsaved edits. Sessions are not preserved across browser restarts.
- Reopening the document later starts fresh against the latest Polarion data — your previous session’s saved changes are visible, and so are changes made by others since.
- Long-running analyses naturally split into many short sessions, each ending with a Save. There is no “session resume” feature beyond Polarion’s normal versioning of work items.
Save and Refresh — No Live Propagation
Edits you make to cells (severity ratings, mitigation text, link selections) accumulate in your browser. They are not pushed to Polarion until you press Save. Likewise, edits another user saves to the same document are not pushed to your browser — you only see them when the grid reloads. This means two different but related things happen at save time:
The key point: there is no real-time channel between Risksheet sessions. Risksheet does not push updates to your grid while you are working. You only see other users’ work after a save-with-refresh or a manual reload.
Refresh on Save and Scroll Position
By default, Risksheet refreshes the grid after each save operation. For large risk tables with hundreds of rows, this refresh scrolls the view back to the top, making it difficult to locate the row you were editing. TherefreshOnSave configuration property controls this behavior. When set to false, the grid preserves your scroll position and focus after saving, keeping you on the last edited cell. The trade-off is that your view will no longer automatically pick up changes saved by other users — you must trigger a manual reload to see them.
Concurrent Editing — Per-Session Isolation
Polarion’s optimistic concurrency model applies to Risksheet edits, but Risksheet itself does not coordinate sessions in real time:
Project Configuration vs. Personal Preferences
A working session draws on two independent layers of configuration. They have very different scopes and lifecycles:
The sheet configuration is administered by document owners or template authors. Changing it affects every analyst working on the document. Personal preferences are yours alone — choosing a different saved view (for example, switching from Initial Risk Ranking to Final Risk Assessment) does not change what your colleagues see.
Because saved views are part of the shared sheet configuration but the current selection is personal, several users can work on the same document at the same time, each looking through a different view that highlights the columns relevant to their stage of the analysis.
The exact set of personal preferences persisted between sessions depends on your Risksheet version and Polarion configuration. If a preference you expect to remember (such as a custom column width) is reset between sessions, confirm with your administrator that user-preference persistence is enabled in your deployment.
Practical Recommendations
A few habits make working across many sessions reliable:- Save before context switches. Save before lunch, before joining a meeting, and before leaving for the day. Treat saves as commit points in your analysis.
- Reload before bulk edits. If you have had the tab open for more than an hour, reload before changing many cells. This pulls in any work your colleagues saved in the meantime.
- Coordinate by chapter or level. For multi-analyst sessions (for example, a HARA workshop), agree in advance who edits which Level 1 group. This avoids silent overwrites.
- Use saved views to focus. Switch to a stage-specific saved view (such as Identify Failure Modes or Mitigations) to reduce visible columns and minimize accidental edits to columns owned by other reviewers.
- Use the configuration editor for shared changes. Modifying the sheet configuration changes the document for everyone — do not edit it during another analyst’s active session unless you have agreed on the change.
- Treat the document, not the session, as the unit of work. Long analyses are a sequence of many short, saved sessions against the same Polarion document, not one long interactive session.
Verification
You should now see:- Each time you open a Risksheet document, a new session begins with a fresh load from Polarion.
- Edits stay in your browser until you press Save; other users only see them after they reload.
- Long analyses naturally span many sessions across days or weeks; the document is the unit of continuity, not the session.
- Saved views and the sheet configuration are shared by everyone working on the document; your selected view, column widths, and expand/collapse state are personal to your user.