> ## Documentation Index
> Fetch the complete documentation index at: https://docs.operata.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Screen recording observability

> Operata reports whether Amazon Connect screen recording actually ran for each contact, by parsing the recording lifecycle out of the CCP logs the Agent Collector captures.

Operata reports whether Amazon Connect screen recording actually ran for each contact. The Agent Collector watches the Contact Control Panel (CCP) log stream, picks out the screen recording lifecycle lines, and ships them as structured telemetry entries tagged `ScreenRecording`.

## Why it matters

Amazon Connect tells you a contact was *flagged* for screen recording. It doesn't tell you the agent's machine recorded it, or that the recording reached S3.

That gap sits on the agent endpoint. Screen recording depends on the Amazon Connect client app — a Windows installer that endpoint management has to deploy to every agent workstation. When the app is missing, blocked, or broken, Amazon Connect still flags the contact, the CCP still creates a recording, and nothing uploads. Nothing in the Contact Trace Record (CTR) tells you this happened.

When screen recording carries a contractual compliance obligation, coverage sits on the critical path. You need to know which contacts recorded, which didn't, and which agents are the reason.

## Before you start

Screen recording telemetry is **off by default**. Three things have to be true:

* **Operata enables it on your group.** The Agent Collector reads a `screenRecordingTelemetry` flag from the collector configuration Operata serves to each group. When the flag is absent, the Collector defaults it to `false` and skips screen recording parsing entirely. Ask Operata support to turn it on.
* **CCP log collection is on.** The parser runs inside the CCP log pipeline. No log collection, no screen recording telemetry.
* **Agent Collector v1.7.29 or later**, on Chrome or Microsoft Edge, with agents on Windows. The Amazon Connect client app ships as a Windows MSI, so macOS agents produce no screen recording at all.

Screen recording telemetry is Amazon Connect only. The Genesys Cloud and NICE CXOne adaptors don't emit it.

## How it works

The Agent Collector hooks the Amazon Connect Streams logger in the agent's browser. For every captured entry at `INFO` level whose text mentions `recording`, it runs the screen recording parser.

The parser matches five lifecycle patterns and turns each into a telemetry entry with `component: "ScreenRecording"`:

| Log line contains                                                             | Entry `text`                                            | Captured in `data`                                         |
| ----------------------------------------------------------------------------- | ------------------------------------------------------- | ---------------------------------------------------------- |
| `New recording`                                                               | `New recording`                                         | `contactId`, `screenRecordingEnabled`, `screenRecordingId` |
| `PUT S3Upload for recording`                                                  | `PUT S3Upload for recording`                            | `blockNumber`, `blockStatus`, `contactId`                  |
| `Detected ended contact` (with a JSON payload)                                | `Detected ended contact - recording end contact object` | The contact summary object                                 |
| `Detected ended contact` (with a JSON payload)                                | `Detected ended contact - recording end task objects`   | `recordingTaskObjs`, `contactId`                           |
| `Received CCP ContactRefreshed event for contact`, or `TAPS.RECORDING.SIGNAL` | The raw log line                                        | `contactId`                                                |

Each entry joins the CCP log stream the Collector already ships, carrying the contact ID, a timestamp, and the standard vendor fields. Operata builds the per-contact screen recording summary server-side from those entries.

```
Amazon Connect flags contact for screen recording
  → CCP creates a recording, client app uploads parts
  → Streams logs each transition at INFO
  → Agent Collector parses matching lines
  → ScreenRecording telemetry entries in the CCP log stream
  → Operata assembles the per-contact summary
```

Two consequences worth knowing. The parser only sees `INFO` entries, so screen recording warnings and errors never become `ScreenRecording` telemetry — they stay ordinary CCP log lines. And the lifecycle payloads come from Amazon's log text, so their shape follows the Streams library, not an Operata contract.

## What's collected

### Recording start

Emitted when the CCP creates a recording.

| Name                     | Type          | Description                                                                      | Example                                |
| ------------------------ | ------------- | -------------------------------------------------------------------------------- | -------------------------------------- |
| `contactId`              | string (UUID) | The contact the recording belongs to.                                            | `04ea96b3-454f-4f65-9767-784e2e99b694` |
| `screenRecordingEnabled` | boolean       | Always `true` on this entry — its presence is the signal that recording started. | `true`                                 |
| `screenRecordingId`      | string (UUID) | The recording the CCP created.                                                   | `69ee35e5-faf5-425c-a727-8a15cd151fe9` |

### Part upload

Emitted once per block the client app pushes to S3. Counting these entries tells you how much of the recording actually left the workstation.

| Name          | Type          | Description                                 | Example                                |
| ------------- | ------------- | ------------------------------------------- | -------------------------------------- |
| `blockNumber` | integer       | The block this upload covers.               | `1`                                    |
| `blockStatus` | string        | Upload outcome as reported in the log line. | `SUCCESS`                              |
| `contactId`   | string (UUID) | The contact being recorded.                 | `04ea96b3-454f-4f65-9767-784e2e99b694` |

### End of contact

When the contact ends, the CCP logs a summary the parser splits into two entries: the contact object, and the array of recording task objects.

Contact object:

| Name                         | Type                   | Description                                                                     |
| ---------------------------- | ---------------------- | ------------------------------------------------------------------------------- |
| `agentId`                    | string (UUID)          | The Amazon Connect agent handling the contact.                                  |
| `contactId`                  | string (UUID)          | The contact the recordings belong to.                                           |
| `initialContactId`           | string (UUID)          | The first contact in the chain. Differs after a transfer.                       |
| `contactState`               | string                 | Contact state at assembly, such as `ENDED`.                                     |
| `contactType`                | string                 | Channel of the contact, such as `VOICE`.                                        |
| `contactStartTimeMillis`     | integer (epoch ms)     | When the contact started.                                                       |
| `contactEndTimeMillis`       | integer (epoch ms)     | When the contact ended.                                                         |
| `contactLastKnownTimeMillis` | integer (epoch ms)     | Last contact state the CCP observed.                                            |
| `recordingTasks`             | array of string (UUID) | Recording task IDs for this contact. An empty array means the CCP created none. |

Each entry in `recordingTaskObjs`:

| Name                           | Type               | Description                                                                                         |
| ------------------------------ | ------------------ | --------------------------------------------------------------------------------------------------- |
| `recordingId`                  | string (UUID)      | The recording task. Matches an ID in `recordingTasks`.                                              |
| `recordingStatus`              | string             | Terminal state of the recording, such as `SUCCEEDED` or `FAILED`.                                   |
| `recordingStartTimeMillis`     | integer (epoch ms) | When capture started.                                                                               |
| `recordingEndTimeMillis`       | integer (epoch ms) | When capture stopped.                                                                               |
| `recordingLastKnownTimeMillis` | integer (epoch ms) | Last recording state the CCP observed. Runs past `recordingEndTimeMillis` while final parts upload. |
| `totalRecordingBlocks`         | integer            | Blocks the client app captured.                                                                     |
| `totalSizeInBytes`             | integer            | Total captured size.                                                                                |
| `numOfPartsUploaded`           | integer            | Parts the client app uploaded. Compare against `totalRecordingBlocks`.                              |
| `latestPartNumReceived`        | integer            | Highest part number the service acknowledged.                                                       |
| `isLastPartReceived`           | integer            | `1` once the final part is acknowledged, `0` until then.                                            |

The Collector passes these through from Amazon's payload without transforming them. Treat the Amazon Connect documentation as the authority on their exact semantics.

## Reading the result

Compliance reporting asks three questions of each contact.

| Question             | Where to look                                                                                                               | Healthy                                                |
| -------------------- | --------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------ |
| Did recording start? | A `New recording` entry for the contact                                                                                     | Present, with a `screenRecordingId`                    |
| Did parts upload?    | `PUT S3Upload for recording` entries                                                                                        | One per block, each with a successful `blockStatus`    |
| Did it complete?     | `recordingStatus` in `recordingTaskObjs`, plus `numOfPartsUploaded` against `totalRecordingBlocks` and `isLastPartReceived` | `SUCCEEDED`, counts match, `isLastPartReceived` is `1` |

The case to chase is a contact with a `New recording` entry and no upload entries behind it. Recording started and produced nothing.

## Failure signatures

**Recording started, nothing uploaded.** A `New recording` entry, then an end-of-contact entry, with no `PUT S3Upload for recording` entries between them. The Amazon Connect client app is missing, not running, or blocked on that workstation. This is the most common cause, and it usually points at an endpoint deployment gap rather than a per-agent fault.

**Recording never started.** The contact was flagged in Amazon Connect, but no `New recording` entry exists and `recordingTasks` comes back empty in the end-of-contact object.

**Partial upload.** Upload entries exist but stop short — `numOfPartsUploaded` trails `totalRecordingBlocks`, or `isLastPartReceived` stays `0`. The workstation lost the network or the app died mid-contact.

Amazon also logs screen recording problems at `WARN` and `ERROR` — stale recording state, recordings marked `FAILED`, contacts dropped for having no recording task. Those lines are **not** captured as `ScreenRecording` telemetry, because the parser only reads `INFO` entries. They do appear in the raw CCP logs when your capture level includes them. Pull the full log for the agent and time range from [Calls and logs](/docs/help/calls-and-logs) and read it with the [CCP log parser](/docs/help/amazon-connect-log-parser).

## Privacy

Operata reads screen recording metadata out of CCP log text. It does not access the recordings themselves — no video, no frames, no screen content, and no access to the S3 bucket the recordings land in. Every field above is parsed from a log line. The Collector has no media path and no S3 credentials.

## Limits

Collection works today. The reporting layer on top of it is still being built.

* **Off by default.** Screen recording telemetry needs Operata to enable the flag on your group. It is not automatic on upgrade.
* **No packaged coverage dashboard.** Operata does not yet ship a screen recording coverage report or a "recording failed" insight. Reach the data through CCP logs and custom dashboards. The packaged report — flagged, recorded, and transmitted as contact attributes visible in Canvas — is on the roadmap.
* **Not in the MCP trace schema.** The [Operata MCP Server](/docs/guides-mcp-intro) exposes the underlying softphone logs through `agent_logs` and `traces_span_logs`, so an AI client can read the raw lifecycle entries. The normalised screen recording summary is not yet part of the CX trace schema, so you can't query it as a structured field.
* **Warnings and errors aren't tagged.** The parser reads `INFO` entries only, so Amazon's screen recording `WARN` and `ERROR` lines stay in the raw log stream rather than becoming screen recording telemetry.
* **Retention on the summary data differs from log retention.** Confirm the current window with Operata support before you build a reporting process on it.
* **Operata can't see whether the client app is installed.** It observes what the CCP logs. A missing client app is an inference from the failure pattern, not a direct reading.
* **Payload shape follows Amazon.** The end-of-contact fields come from the Streams log text and can change when AWS changes the library.

## Related

* [Agent Collector](/docs/collector-overview) — the browser-side collector that captures this data.
* [CCP error logs](/docs/ccp-error-logs) — the other log stream the Collector attaches to each contact.
* [Tools and logs](/docs/diagnose-tools-and-logs) — getting raw logs out of Operata.
* [Data collection — Amazon Connect](/docs/resources-data-collection-amazon-connect) — the full collection picture for Amazon Connect.
* [Amazon Connect screen recording](https://docs.aws.amazon.com/connect/latest/adminguide/faq-screenrecording.html) — AWS requirements and setup.
