Access control

• Latest Dynatrace
• Explanation
• Published Jun 17, 2026

Dynatrace Synthetic is fully integrated into the Latest Dynatrace platform as Synthetic Monitoring (formerly known as Synthetic on Grail). This page explains how to access Synthetic configuration, entities, and data across all platform entry points— Synthetic, Notebooks, Dashboards, and API—along with the required permissions, security contexts, and how classic permissions apply in Latest Dynatrace.

Overview

In Latest Dynatrace, access to Synthetic Monitoring covers three categories:

All three categories are accessible from multiple platform entry points. Once the appropriate permissions are in place, the same configuration, entities, and data are available wherever you work.

All entry points rely on the same underlying IAM permissions, described in the next section.

Permissions

Access to Synthetic data across all platform entry points is controlled by IAM policies. Assign IAM policies to users or groups in Account Management > Identity & access management > Policies.

Monitor and location configuration

These permissions control who can view, create, modify, and execute Synthetic monitors and locations. Dynatrace checks them when you use Synthetic or call the Synthetic API.

Credentials

These permissions control access to credential vault entries used in Synthetic monitor authentication.

Synthetic data (metrics and events)

These permissions control access to Synthetic results stored in Grail, including availability metrics, response times, execution events, and waterfall data. In addition to Synthetic result views, they're required for Dashboards, Notebooks, DQL queries, and API metrics.

Entities

This permission controls access to monitored entity records—the Synthetic monitor and location objects as they appear in the entity model (used for filtering, correlation, and entity-centric views).

Default policies

Dynatrace provides built-in default policies that can be assigned to user groups without custom configuration. Dynatrace maintains these policies and keeps them up to date with platform changes.

The following default policies include Synthetic-relevant permissions:

Default policies can be assigned to user groups at the account level (where they apply to all environments), or at the environment level. You can find them in the policy overview in Account Management.

For details, see Default policies.

Example access patterns

The following examples are suggested starting points for common Synthetic user types. Each pattern requires a Dynatrace access policy for feature access and a data access policy for Grail data visibility.

View only

Dynatrace access permissions:

Data access policy: Storage Default Monitoring Read, which covers Synthetic metrics, events, and entities.

View and execute

Dynatrace access permissions include all those listed above, plus:

Data access policy: Storage Default Monitoring Read.

Full monitor management

Dynatrace access permissions include all those listed above, plus:

Data access policy: Storage Default Monitoring Read.

Security context

Security contexts are values set on individual Synthetic monitors that allow fine-grained access control. If you're familiar with Dynatrace Classic, you can think of security contexts as serving a similar purpose to management zones. Instead of grouping entities into zones, you set security context values on monitors and scope IAM policies accordingly.

How security context works

A monitor can have one or more security context values. You can grant platform permissions in two ways:

This means two users can both have synthetic:monitors:read, while one user sees all monitors and the other sees only monitors whose security context matches the values allowed by their policy.

Rules for creating monitors with security context

Configure security context boundaries in IAM policies

To limit a permission to specific security contexts, add a condition to the policy statement.

ALLOW synthetic:monitors:read
WHERE synthetic:dt.security_context IN ("team-a", "platform-ops");

A user with this policy has platform API access only to monitors with the team-a or platform-ops security context.

To ensure limited access to entities in Synthetic, Dashboards, and Notebooks, combine Synthetic permissions with storage:smartscape:read and a storage:dt.security_context boundary.

ALLOW storage:smartscape:read
WHERE storage:dt.security_context IN ("team-a", "platform-ops");

Split monitors between teams on a shared tenant

Multiple teams sharing the same Dynatrace tenant often need isolated visibility—each team should see and manage only their own monitors, without access to monitors owned by other teams.

Assign a distinct security context value to each team's monitors (for example, team-a and team-b), then create a separate IAM policy for each team that conditions all Synthetic permissions on that value:

ALLOW synthetic:monitors:read, synthetic:monitors:write, synthetic:monitors:execute
WHERE synthetic:dt.security_context IN ("team-a");

ALLOW storage:metrics:read, storage:events:read, storage:user.events:read
WHERE storage:dt.security_context IN ("team-a");

Users in the team-a group can create and manage monitors, trigger executions, and view results—but only for monitors that carry the team-a security context. Monitors belonging to team-b aren't visible to them, and vice versa.

Separate Synthetic and RUM data access

Organizations often need to give certain users access to Synthetic data only, without exposing RUM data. This is a common requirement for teams that manage Synthetic monitors but have no responsibility for real user monitoring.

The challenge is that storage:user.events:read, which is required by Synthetic to display execution events, also covers RUM user events. Granting it without a condition provides access to both Synthetic and RUM data.

Security contexts solve this because user events generated by Synthetic monitors are enriched with the security context values set on those monitors. This means the storage:dt.security_context condition works for storage:user.events:read the same way synthetic:dt.security_context does for synthetic:monitors:* permissions.

The following policy grants access to Synthetic monitors and their execution events, scoped to a specific security context, without exposing any RUM data:

ALLOW synthetic:monitors:read, synthetic:monitors:execute
WHERE synthetic:dt.security_context IN ("synthetic-only");

ALLOW storage:metrics:read, storage:events:read, storage:user.events:read
WHERE storage:dt.security_context IN ("synthetic-only");

A user with this policy can open Synthetic, view monitors tagged with synthetic-only, and see their execution results, but user events from RUM sessions, which carry no synthetic security context, remain outside the scope of their storage:user.events:read permission.

Management zone sync

With the rollout of Dynatrace version 343, Dynatrace performs a one-time synchronization for environments created before January 2026. During this synchronization, the management zones each Synthetic monitor belongs to are mapped to security context values with identical names on that monitor. This preserves the existing grouping structure without requiring manual reassignment.

The synchronization doesn't continue after the Dynatrace version 343 rollout. New management zones aren't propagated as security context values, monitors created after the rollout don't receive security context values from management zone membership, and changes to management zone assignments aren't reflected in security contexts, on both existing and new monitors.

API access

Authentication

The Synthetic Platform API authenticates requests using a bearer token in the Authorization header.

Authorization: Bearer <token>

Dynatrace supports the following authentication mechanisms:

Synthetic Platform API

The Synthetic Platform API is the dedicated API surface for Synthetic in Latest Dynatrace. It's separate from the classic Environment API.

Base URL:

https://<environment-id>.apps.dynatrace.com/platform/synthetic/v1

The OpenAPI specification is available at /platform/synthetic/v1/openapi.yaml. You can explore it in Dynatrace API.

Permissions setup

This section explains how to set up Synthetic permissions in Latest Dynatrace and how to map classic role-based permissions to the IAM model.

For administrators

New environments

For environments created in Latest Dynatrace, there are no classic permissions to migrate. Assign IAM policies directly to user groups in Account Management > Identity & access management > Policies. Use the permissions reference and example access patterns on this page to build policies that match each group's responsibilities. The Example access patterns section provides a starting point.

Environments with existing classic permissions

Classic role-based permissions continue to work during the transition, but Dynatrace recommends migrating to IAM policies. The table below maps the relevant classic permissions to their Latest Dynatrace equivalents.

Go to Account Management > Identity & access management > Policies, create or update policies with the required permissions, and assign them to the relevant user groups. For the full procedure, see Upgrade role-based permissions to IAM policies.

Replace classic access tokens used for API automation with OAuth clients. For details, see API access.

For users

Access to Synthetic in Latest Dynatrace is controlled by IAM policy permissions assigned to your user group by an administrator. Use the following table to identify the permissions required for common Synthetic tasks.

If you can't access Synthetic or you see missing data, ask your Dynatrace administrator to verify that the required IAM policy permissions are assigned to your group for the target environment.

Classic permissions

Classic role-based permissions remain functional in Latest Dynatrace. Users who have them can access Synthetic monitors through the same platform entry points as other users. The difference is in how access is controlled.

The following classic permissions apply to Synthetic:

Classic access tokens provide equivalent API-level access and are managed in Settings > Integration > Dynatrace API.

Managing Synthetic with classic permissions requires tenant-wide administrative access. You can't scope classic permissions to a subset of monitors. Users whose classic permissions are limited to a management zone can still create monitors through Synthetic Classic, but those monitors won't be visible in Latest Dynatrace.

If you need to grant users access to specific monitors only, migrate to Latest Dynatrace IAM policies and use security contexts to define precise access boundaries. This gives you fine-grained, attribute-based access control (ABAC) across Synthetic, Dashboards, Notebooks, and the API without requiring tenant-wide admin rights.