> ## Documentation Index
> Fetch the complete documentation index at: https://learn.nextedy.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Working Sessions
> A working session is the period between opening a Nextedy RISKSHEET grid in your browser and the next save or reload.
export const LastReviewed = ({date}) => {
if (!date) return null;
const formatted = new Date(`${date}T00:00:00Z`).toLocaleDateString("en-US", {
year: "numeric",
month: "long",
day: "numeric",
timeZone: "UTC"
});
return
Last reviewed on {formatted}
;
};
This page explains how Risksheet handles long-running analysis work, how save and refresh interact with the underlying Polarion data, why concurrent editing requires explicit coordination, and how project-level configuration is separated from each user's personal preferences.
## 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.
Treat **Save** as a checkpoint. If a meeting interrupts you, save first — even partially completed edits — rather than leaving the tab open with unsaved work for hours. This protects you from accidental tab closures and frees the work for review by colleagues.
## 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:
| Action | What it does |
| ------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Save** | Sends your accumulated edits to Polarion as a batch. After a successful save, your browser displays values consistent with what was just written. |
| **Refresh on save** | Optionally re-fetches the document from Polarion immediately after saving so your view also reflects changes made by other users since you opened the grid. Controlled by the `refreshOnSave` setting in the `global` section of the sheet configuration. |
| **Manual reload** | Pressing your browser's reload (or navigating back to the document) discards unsaved edits and shows the current server state. Use this when you want to see other users' latest saved changes. |
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.
If you keep a Risksheet tab open for hours and another analyst saves changes during that time, your grid will still show the data from when you first opened it. Saving from a stale view can overwrite recent work. When in doubt, reload before making significant edits.
### 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.
The `refreshOnSave` 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.
For risk tables with more than 50-100 rows, setting `refreshOnSave` to `false` significantly improves the editing experience by eliminating the scroll-to-top behavior after each save.
## Concurrent Editing — Per-Session Isolation
Polarion's optimistic concurrency model applies to Risksheet edits, but Risksheet itself does not coordinate sessions in real time:
While two analysts have the same document open, each sees only what was on the server when they loaded the grid plus their own local edits. Risksheet does not show that someone else is editing, and it does not lock rows. The first save is committed normally; a second save against the same work items succeeds as long as the underlying Polarion fields have not been changed by the first save in conflicting ways. If they have, Polarion may reject the save and you must reload to see the current state and re-apply your changes.
Because there is no real-time conflict indicator, two analysts editing the same risk item at the same time can silently overwrite each other on save. Coordinate by row range (for example, by failure-mode chapter) or by Risksheet view, and reload before saving if you suspect someone else has been active.
## Project Configuration vs. Personal Preferences
A working session draws on two independent layers of configuration. They have very different scopes and lifecycles:
| Layer | Scope | Examples | Where stored |
| ------------------------ | ----------------------------------------- | ----------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------ |
| **Sheet configuration** | The document (shared by all users) | Columns, levels, formulas, cell decorators, styles, saved views, review setup | Sheet configuration attached to the Polarion document (editable through the YAML editor since v25.5.0) |
| **Personal preferences** | Your user account on this machine/browser | Currently selected saved view, column widths you have adjusted, expanded/collapsed groups, sort order | Per user, per browser — kept across sessions for the same user |
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:
1. **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.
2. **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.
3. **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.
4. **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.
5. **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.
6. **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.
## See also
* [Data Synchronization](/risksheet/concepts/data-synchronization)
* [Review Workflows](/risksheet/concepts/review-workflows)
* [Configuration Hierarchy](/risksheet/concepts/configuration-hierarchy)
* [User Roles and Permissions](/risksheet/concepts/user-roles)