topic Scenario: Restrict Team to only their MZ (Synthetic + Hosts) in New UI in Synthetic Monitoring

Scenario: Restrict Team to only their MZ (Synthetic + Hosts) in New UI

n_957 — Tue, 17 Feb 2026 08:08:36 GMT

We have Team ABC and they own a Management Zone (MZ) = XYZ in Dynatrace.

We want to provide New UI access to Team ABC users, but restrict them so they can only see:

Synthetic monitors that belong to MZ XYZ
Hosts / infrastructure entities that belong to MZ XYZ

What we did so far

Created a policy that includes permissions for:
- Hosts / Infrastructure (view)
- Synthetic monitors (view) (and results if needed)
Applied a policy boundary to restrict access in the New UI.

Problem / Question

Even after creating the policy + boundary, we are not clear on how to ensure entity-level restriction so Team ABC users can only see Synthetic monitors and Hosts that are in their Management Zone XYZ (and not monitors/hosts belonging to other teams/MZs).

Question: What is the correct way (best practice) to restrict visibility to only entities included in a specific Management Zone (XYZ) in the Dynatrace New UI for:

Synthetic monitors
Hosts (infra)

What guidance we are looking for

Should the boundary be configured specifically as a Management Zone boundary (XYZ)?
Are there any additional permission sets required (or permissions to avoid) that may “leak” visibility outside the MZ?

It would be helpful if Dynatrace provided clearer guidance (or simplified configuration) on how to enforce entity-level scoping by Management Zone for Synthetic and Infrastructure in the New UI using policies and boundaries.

Thanks.

Re: Scenario: Restrict Team to only their MZ (Synthetic + Hosts) in New UI

t_pawlak — Tue, 17 Feb 2026 12:54:47 GMT

Hi,
As I understand, you want Team ABC can see only Synthetic monitors + Hosts that belong to MZ XYZ in the New UI is typically enforced not by Management Zone alone, but by Grail security context (dt.security_context) + IAM policies/boundaries.
New UI Synthetic app is Grail-based and requires storage:* permissions (entities/metrics/events…). Grail doesn’t use Management Zones for record-level access control—MZ is primarily a classic UI partition/filter, while Grail ABAC is done via storage: fields.
link to documentation:
Policy boundaries
I think you can try this approach:

1. Tag the entities (Hosts + Synthetic) with dt.security_context, e.g. XYZ.

2. Create a policy boundary on that security context, e.g.
storage:dt.security_context = "XYZ";

3. Grant only minimal storage:* read (e.g. storage:entities:read, storage:metrics:read, storage:events:read + optionally document:*) and apply the boundary to the group binding.

Should the boundary be on the MZ?
You can reference MZ in boundaries (environment:management-zone ...) only where supported. For Synthetic in the New UI (Grail), reliable entity-level scoping is storage: + dt.security_context, not MZ.

Common “leaks”: broad environment-wide grants and mixing role-based permissions with IAM.

What MZ still provides: mainly filtering/partitioning in views, not always hard ABAC for Grail data.

To make building and validating these policies easier, I recommend using:
Omnilogy- Policy Manager

Re: Scenario: Restrict Team to only their MZ (Synthetic + Hosts) in New UI

n_957 — Tue, 17 Feb 2026 16:50:52 GMT

Hello t_pawlak,

Thank you for the reply and details. I will check and keep you posted.