Configure access to Synthetic data

• Latest Dynatrace
• How-to guide
• 5-min read
• Updated on Oct 01, 2026

The platform IAM model with security contexts lets you scope access to individual monitors or groups. After the upgrade, access to Synthetic monitors and data is controlled by IAM policies.

For the full permission reference, including IAM permissions, default policies, example access patterns, and security-context setup, see Synthetic access control.

Required permissions

Assign these permissions through IAM policies. They apply both to users working in the UI and to API automation, whether it uses a platform token or an OAuth client.

Replace management-zone access rules

In Latest Dynatrace, use security contexts and IAM policy boundaries to control access to Synthetic data. The management-zone migration tool helps you seed security contexts from your existing management zones.

Security contexts were seeded once automatically from the management zones of each monitor, so running the tool is not mandatory. Use it to pick up management-zone changes made after that automatic synchronization.

To seed security contexts from existing management zones, use the Set security contexts for synthetic monitors tool available in Synthetic > Settings > Migration. It copies each monitor's management-zone names as security-context values. Choose the strategy that fits your situation before running it:

The tool affects only Synthetic monitors. Other entity types and your management-zone configuration are not changed. Security contexts are not updated automatically when management zones or monitors change later; re-run the migration manually when needed. Running it again applies the selected mode to the current state of your monitors. The migration does not activate IAM-based access control by itself.

After running the tool, review the assigned values and configure IAM policy boundaries for both Synthetic access and data storage access.

Recreate filtering with segments

If a management zone was used to filter Dashboards or views rather than restrict access, recreate that user-facing filter with a segment or an equivalent DQL filter. A segment changes which data a view displays; it does not grant or deny access to that data. Test segmentation and access control separately.

Classic: selecting management zone "team-payments" in the environment header or a dashboard variable scoped all tiles automatically via an implicit entity selector:

entitySelector: type(SYNTHETIC_TEST),mzName("team-payments")

Latest Dynatrace: filtering is explicit. Either apply a segment at the dashboard level (segment definition example):

fetch dt.synthetic.browser.availability
| filter dt.security_context == "team-payments"

Or add the filter directly to each tile's DQL query:

smartscapeNodes BROWSER_MONITOR
| filter dt.security_context == "team-payments"
| fields id, name

The segment approach filters every tile in the dashboard at once; the per-tile approach gives finer control. Both are view-only; neither blocks access to data outside the filter.

For step-by-step instructions, including a segment based on security context, see Create a segment to filter Synthetic data. To filter by primary Grail tags instead, see Primary Grail tags for Synthetic.

Validate private-location enrichment

To confirm security-context enrichment, run representative monitors from each private location and verify that the expected security-context values appear in the resulting metrics and events.

API access

If you automate Synthetic monitor management through the API, see Migrate Synthetic API automation for the required endpoint, authentication, and permission changes.

Verify the upgrade

Test each role with a representative user