Employee Monitoring: Monitoring - Screen Recordings
Objective. Read the Screen Recordings page and demo it safely: name the per-user recording grid, the Live player and the Past Recording controls (window and app selectors), explain that motion capture is policy-driven and transparent, and use a recording as evidence to investigate with context rather than as a verdict on a person.
Screen Recordings is the moving-picture sibling of Screenshots and is equally privacy-sensitive, so the guardrail leads: screen recording is a policy-driven, consent-based, configurable capture that exists to answer a question with evidence, not to watch people. The page is a per-user grid of recording cards; opening one gives a player with a Live mode and a Past Recording mode that can be filtered by window and application. All content is seeded demo data.
See it in the demo
What this page answers
Lead with the guardrail: screen recording is an administered, transparent, configurable control - whether it runs, for whom, and who may view it is a policy the customer sets and tells employees about, not a blanket on-switch. Hold that frame and the page becomes ordinary.
With it, the page answers for the team and day I picked, what did the screen actually show over time when I need to look? It is the motion version of Screenshots: where a screenshot is one frame, a recording shows the sequence. An investigator opens it when a flag needs more than a still - to see how an action unfolded. It lives under Monitoring; the sub-tabs are Screenshots, Screen Recordings, Keystrokes, Sound Recordings, with the same date, prev/next and GMT controls and a per-user focus.
On the page, panel by panel
The grid. The body is a paged grid of per-user recording cards. Each card shows a video thumbnail with a Play overlay, the person's avatar and name, a coloured status ring, and a one-line label of the active application and window captured (in the demo, labels like Google Chrome - Sea... and Post - LinkedIn). The demo paged this as 1-20 of 36 users with a Show 20 / 30 / 50 per page control. So each card is one person and surfaces the app they were last recorded in.
The player (open a card). Clicking a card opens the shared viewer. In Live mode it shows a red Live dot, a full timestamp, the live screen, a Close button, and at the bottom the person's avatar and name, a Stop Recording control and a Past Recording / Live toggle. Switching to Past Recording changes the header to Past Recording with its own timestamp and adds two selectors at the top: a window / activity dropdown (in the demo, Post - LinkedIn - Google C...) and an application dropdown (in the demo, LinkedIn) so the viewer can jump to a specific captured window or app. This is the same player the Screenshots tab uses.
How it is used
Like Screenshots, this is an evidence lookup, not a browse-everything screen. A question arrives from elsewhere, the investigator opens the one person's card, and uses Past Recording with the window and app selectors to go to the relevant segment - because a recording is long, the selectors are how you reach the moment that matters instead of scrubbing blindly. The decision is narrow (does the motion support or dismiss the flag) and is always read with surrounding context.
The drill path: a recording is typically opened after a signal on Overview, Suspicious Activity or Behaviors, and it sits alongside Screenshots, Keystrokes and Sound Recordings as the capture surfaces available where policy allows. Use motion when a still is not enough to understand a sequence.
How to read it right
One: a recording is a signal, not a verdict. It shows what was on screen over a span, not intent, not work done in another system, and not whether the person was legitimately busy off-agent. Investigate with context before any conclusion.
Two: the app and window labels are what the agent captured, not a classification. The Google Chrome or LinkedIn label says where the window was, not whether the time was productive - productivity labelling is a separate, configured concern. Three: capture is governed and therefore partial - no policy, agent off or offline means no recording, which is a coverage fact, not evidence about the person. Four: everything is seeded demo data on a fixed fictional day - the people, the LinkedIn and Chrome windows and the timestamps are illustrative. Five: Stop Recording is a capture control, not a disciplinary act, and should never be read as one.
How to demo and sell it
Open on the boundary, not the play button: screen recording is a policy you set and employees are told about; it produces evidence for a specific question, it is not continuous watching. Then open a card, switch to Past Recording, and show the window and app selectors - because the honest, impressive point is precision: you can go straight to the relevant moment and the relevant application, which is how a real investigation works, rather than trawling someone's whole day. Land one value point: when a still is not enough - a security incident, a process dispute - you can see exactly how it unfolded, inside an agreed policy. Make the honesty move first: a recording is a prompt to investigate with context, never a verdict. Discovery question: when something goes wrong today, can you reconstruct what actually happened on screen - and can you defend how you captured it?
Honest limits
A recording proves what was displayed over a span - not productivity, not output quality, not intent, and not that off-screen or off-agent work did not happen. Whether recording runs, retention length, in-scope teams and who may view playback are customer-configured and jurisdiction-dependent; confirm the exact modes, retention and access with product, and never imply covert or always-on recording. Whether Live view, Stop Recording and the Past Recording window/app selectors behave in production as in this demo is SME-validation-pending. Written employee communication about what is recorded and why is a real compliance and adoption dependency. Treat every clip, label, name and timestamp as seeded demo data.
Interpretation check
A screen recording is a policy-governed signal to investigate with context, not a verdict: it shows what was on screen over time, not intent or output, and the app and window labels say where a window was, not whether the time was productive. Capture is configurable and consent-based, so no recording means capture was off, not that no work happened.
In the field
For a KnackGlobal-scale RCM operation under incumbent-displacement pressure, the sellable point is investigation-grade evidence with boundaries: when a genuine security or process incident occurs, a leader can reconstruct how it unfolded and jump straight to the relevant app and window, inside a recording policy compliance approved and employees were told about - evidence, not surveillance.
Practical task
On the demo Screen Recordings page, open a card, switch to Past Recording, and use the window and application dropdowns to describe what an investigator would do to reach a specific moment. Then write the one-line boundary statement and the one value point you would lead a prospect with before pressing Play.
Self-check
A manager wants to act immediately on a recording that shows LinkedIn. Why do you slow them down?
Because the window label shows where the screen was, not intent or whether it was a legitimate task, and not what happened in other windows or off-agent. A recording is a signal to investigate with context, not proof of wrongdoing. Pull surrounding evidence first.
What do the two dropdowns in the Past Recording view do, and why do they matter in an investigation?
One selects the captured window or activity, the other filters by application. They let the investigator jump straight to the relevant segment and app instead of scrubbing the whole recording - which is both faster and a more defensible, targeted way to investigate.
How is Screen Recordings different from Screenshots, and when would you use each?
Screenshots is single frames; Screen Recordings is motion over time. Use a screenshot when a still answers the question; use a recording when you need to see how a sequence unfolded. They share the same per-user grid and the same Live/Past viewer.
In a demo, what do you say before you press Play on anyone's recording?
That recording is a policy the customer sets and employees are told about, it produces evidence for a specific question, and it is not continuous watching. Establish the boundary first, then show the capability - and show Past Recording's precision as the honest, investigation-grade point.
The demo shows recordings for 36 of the in-scope users on this day. What does a missing user mean?
That there is no recording in scope for them - most likely recording is not enabled for their team by policy, or the agent was off or offline. It is a coverage fact, not evidence about the person, and every figure here is seeded demo data.
Verified vs demo. The per-user recording grid with Play thumbnails, avatars, status rings and active-application labels (for example Google Chrome and Post - LinkedIn), the pagination (1-20 of 36), and the shared viewer with its Live mode and Past Recording mode (including the window/activity and application selector dropdowns) were read live on the demo at /monitoring/recordingscreens. All clips, labels, names, timestamps and the fixed date are seeded demo data. Whether recording runs, retention, in-scope teams, access, and the Live and selector behaviour in production are customer-configured and jurisdiction-dependent - confirm with product.