Session Replay requires the RUM app and table permissions described in Upgrade your permissions and segmentation configuration. This page covers only what Session Replay adds on top of that.
In Dynatrace Classic, two dedicated, privacy-gated permissions are available at the environment level and the management-zone level. You set them per user group under Manage user groups and permissions:
For details about Classic permissions, see Role-based permissions and Configure Session Replay for web applications.
In Latest Dynatrace, Session Replay uses these IAM permissions. For all permissions that you need for RUM, see RUM permissions.
| IAM permission | Purpose |
|---|---|
storage:user.replays:read | Access Session Replay data. Masking still applies, which is equivalent to "with masking". |
session-replay:resources:read | Access captured CSS resources |
session-replay:sessions:replay-without-masking | Replay without playback masking (optional) |
The ready-made policy Read User Replays grants the first two permissions, so it covers "Replay session data with masking". There's no ready-made policy for "without masking". Write a custom statement with session-replay:sessions:replay-without-masking instead. For details about ready-made policies, see Dynatrace default policies reference.
If Classic roles were migrated automatically for a group, it may instead have one of two legacy policies: Environment role - Replay session data or Environment role - Replay session data without masking. These exist only to preserve that migrated access. Don't assign them to new groups; use Read User Replays instead.
For groups that had Replay session data with masking, bind Read User Replays in addition to the permissions from Upgrade your permissions and segmentation configuration. For details about policies, see Working with policies.
For groups that had Replay session data without masking, also create and bind this policy statement:
ALLOW session-replay:sessions:replay-without-masking;
In Latest Dynatrace, Session Replay data is stored in the user.replays table in Grail. For now, you can't configure how user.replays is stored. You can't assign custom buckets, as you can for user.events and user.sessions, you can't change the retention unless you take part in the Extended Retention for RUM & Synthetic preview, and you can't configure OpenPipeline for replay data.
In Dynatrace Classic, if a user's session spans applications in different management zones, the user can still open and replay it. Parts tied to applications outside the user's zone are masked, and hidden entirely if the user also lacks the Replay permission. In short, a user needs both app access (via the zone) and the Replay permission to see a given part of a session.
Management zones aren't available in Latest Dynatrace. You can scope replay access only by frontend name. You can't configure dt.security_context or primary tags (primary_tags.*) for user.replays, so you can't use them in policy conditions for replays.
If you scoped your RUM data by frontend name, apply the same WHERE condition to the replay permission too (see Upgrade your permissions and segmentation configuration), for example:
ALLOW storage:user.replays:read WHERE storage:frontend.name="checkout_app";
This keeps replay access aligned with event and session access.
Once you have completed all steps for upgrading your Session Replay permissions and segmentation configuration, continue with verifying and completing the upgrade.