> ## Documentation Index > Fetch the complete documentation index at: https://syteca.com/docs/llms.txt > Use this file to discover all available pages before exploring further. # Which Sessions a User Can See > How Syteca decides which monitored sessions a Management Tool user can see and open, from the combination of Endpoint permissions and the Viewing Monitoring Results administrative permission. Granting an investigator access to one alert used to mean granting them access to every session recorded on that endpoint. From 7.28.400, session visibility can be scoped to just the sessions that triggered an alert. This page explains how the final answer is reached, because it comes from two independent inputs rather than one setting. If you are looking for what an individual permission grants, see [Endpoint permissions](https://syteca.com/docs/administration/users/client-permissions.md) and [Administrative permissions](https://syteca.com/docs/administration/users/administrative-permissions.md). ## How session visibility is decided Two things are decided separately: | Question | Decided by | | - | - | | **Which sessions appear in the list?** | The user's [Endpoint permissions](https://syteca.com/docs/administration/users/client-permissions.md) for that endpoint or endpoint group | | **Can the user open and play one?** | The administrative [Viewing Monitoring Results](https://syteca.com/docs/administration/users/administrative-permissions.md#viewing-monitoring-results) permission | A user can therefore see that a session exists, and the alert that fired in it, without being able to watch it. That combination is deliberate: it lets an auditor confirm an incident was recorded without granting them the recording itself. > [!NOTE] > > The two Endpoint permissions and the administrative permission are independent. Neither Endpoint permission implies the administrative one, and the administrative one on its own reveals no sessions. ## The two Endpoint permissions | Permission | Which sessions it reveals | | - | - | | **Viewing All Monitoring Results** | Every session recorded on that endpoint. | | **Viewing Alerted Sessions** | Only sessions that contain a triggered alert. | An **alerted session** is a session for which at least one alert event was triggered and associated with it. Granting both is the same as granting **Viewing All Monitoring Results** alone: the broader grant wins. Granting neither reveals no sessions on that endpoint at all. > [!WARNING] > > Visibility is evaluated **per endpoint and endpoint group, not globally**. A user can hold Viewing All Monitoring Results on one endpoint group and Viewing Alerted Sessions on another, and will see all sessions from the first and only alerted sessions from the second. There is no single deployment-wide setting that overrides this. > [!NOTE] > > **Viewing Alerted Sessions** is enabled by default for the built-in `admin` user and for the **Administrators** endpoint group. It is disabled by default for every other newly created user or group. ## Session visibility matrix | Endpoint permission | Admin Viewing Monitoring Results | Endpoint Sessions | Alerts | Can open a session | Dashboards, Reports, Activity Monitoring, File Upload Monitoring, Forensic Export History | | - | - | - | - | - | - | | None | No | Nothing | Nothing | No | Not available | | None | Yes | Nothing | Nothing | No | Available, no data | | Viewing Alerted Sessions | No | Alerted sessions only | Alert events from alerted sessions | No | Not available | | Viewing Alerted Sessions | Yes | Alerted sessions only | Alert events from alerted sessions | Yes | Available, alerted session data only | | Viewing All Monitoring Results | No | All sessions | All alert events | No | Not available | | Viewing All Monitoring Results | Yes | All sessions | All alert events | Yes | Available | | Both | No | All sessions | All alert events | No | Not available | | Both | Yes | All sessions | All alert events | Yes | Available | ## Archived sessions Archived sessions add a third input: the administrative **Viewing Archived Data** permission. Without it the Archived Sessions page is inaccessible, including by direct URL, whatever Endpoint permissions the user holds. | Endpoint permission | Admin Viewing Archived Data | Admin Viewing Monitoring Results | Archived Sessions page | | - | - | - | - | | Any, or none | No | Any | Not accessible, including by direct URL | | None | Yes | Any | No archived sessions shown | | Viewing Alerted Sessions | Yes | No | Alerted archived sessions listed, cannot be opened | | Viewing Alerted Sessions | Yes | Yes | Alerted archived sessions listed, can be opened | | Viewing All Monitoring Results | Yes | No | All archived sessions listed, cannot be opened | | Viewing All Monitoring Results | Yes | Yes | All archived sessions listed, can be opened | | Both | Yes | No | All archived sessions listed, cannot be opened | | Both | Yes | Yes | All archived sessions listed, can be opened | > [!NOTE] > > **Viewing Archived Data** lists archived sessions. It does not open them. A user can hold it, see the archive listed, and still be unable to play anything in it, because playback needs **Viewing Monitoring Results** as well. ## Where the scoping shows up For a user who holds the administrative Viewing Monitoring Results permission, every page that reports on sessions is limited to the sessions that user is allowed to see: | Page | What is limited | | - | - | | **Endpoint Sessions** | The session list itself. | | **Alerts** | The alert events shown. | | **File Upload Monitoring** | Only file upload events from sessions the user can see. | | **Forensic Export History** | Only export records from sessions the user can see. With Viewing Alerted Sessions, only records from alerted sessions. | | **Reports** | Generated from the permitted session set only. | | **Dashboards** | Charted from the permitted session set only. | > [!NOTE] > > Where a user's permitted session set for an endpoint is empty, these pages show a correct empty state for that endpoint. They do not show an error, and they do not fall back to showing everything. ## Worked examples > [accordion] An investigator who should only see incidents > > Grant **Viewing Alerted Sessions** on the endpoint groups in scope, plus the administrative **Viewing Monitoring Results**. > > They see and can play sessions where an alert fired, generate reports and dashboards covering those sessions, and nothing else. Sessions with no alert are not listed for them. > [accordion] An auditor who confirms incidents without watching recordings > > Grant **Viewing Alerted Sessions** and withhold the administrative **Viewing Monitoring Results**. > > They see that alerted sessions exist and which alerts fired, and cannot open any of them. The Dashboards, Reports, Activity Monitoring, File Upload Monitoring, and Forensic Export History pages are unavailable. > [accordion] A regional split > > Grant **Viewing All Monitoring Results** on the endpoint group for one region and **Viewing Alerted Sessions** on another, to the same user. > > Everything is visible in the first region, and only alerted sessions in the second. Visibility is worked out per endpoint group, so the narrower grant is not widened by the broader one elsewhere. > [accordion] A user who can see nothing, despite having permissions > > If the Endpoint Sessions page is empty, check the Endpoint permissions first. Holding the administrative **Viewing Monitoring Results** alone reveals no sessions: it opens the pages, but something has to populate them. ## Related > [card] [Endpoint permissions](https://syteca.com/docs/administration/users/client-permissions.md) > > Viewing Alerted Sessions, Viewing All Monitoring Results, and the rest. > [card] [Administrative permissions](https://syteca.com/docs/administration/users/administrative-permissions.md) > > Viewing Monitoring Results and Viewing Archived Data. > [card] [Users and user groups](https://syteca.com/docs/administration/users/users.md) > > Where these permissions are granted. > [card] [Alerts](https://syteca.com/docs/session-monitoring/alerts.md) > > What makes a session an alerted session. > [card] [Sessions list](https://syteca.com/docs/session-monitoring/sessions-list.md) > > The Endpoint Sessions page this scoping applies to. > [card] [Archived sessions](https://syteca.com/docs/session-monitoring/archived-sessions.md) > > How the archive is scoped separately. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.