Try it free

Upgrade your permissions and segmentation configuration

  • Latest Dynatrace
  • How-to guide
  • 1-min read
  • Published Oct 06, 2026

In Dynatrace Classic, permissions together with management zones control access to RUM. A management zone determines which applications a given permission applies to. In Latest Dynatrace, permissions are replaced by IAM policies, and management zones have been removed. To achieve the same per-application scoping, you must add a WHERE condition to the IAM policy. Most commonly, you filter on storage:frontend.name (the application name). Because management zones no longer exist, this is a breaking change for anyone who relied on them to restrict RUM access.

Permissions

What changed

In Dynatrace Classic, RUM data access requires the baseline View environment permission. Two related permissions cover sensitive data:

  • View sensitive request data: View personal data captured by Dynatrace, which is otherwise masked as *****.
  • Manage capturing of sensitive request data: An admin permission to configure which data RUM captures, for example HTTP headers or POST parameters, for storage, filtering, and search.

For details about Classic permissions, see Role-based permissions.

In Latest Dynatrace, RUM is delivered as three apps: Experience Vitals Experience Vitals, Error Inspector Error Inspector, and Users & Sessions Users & Sessions. To use them, you need the app permissions. To read the underlying data in Grail, you need the table permissions. Sensitive fields, such as client IP addresses, geolocation, and user identifiers, need an additional grant. See Field permissions.

RUM settings (builtin:rum* schemas) follow the standard Settings permission model: read access for all RUM users, and write access if you configure frontends. See Settings permissions.

What to do

  1. Grant your groups the app permissions and table permissions, either individually or through the Standard User or Pro User policies. For details about policies, see Working with policies.
  2. For groups that need to see sensitive fields, grant the field permission.
  3. Grant read access to the RUM settings for all RUM users, and write access for users who configure frontends.

Management zones

What changed

In Dynatrace Classic, you assign applications to management zones via management zone rules. A user who is restricted to a zone only sees RUM data for the applications in that zone.

Management zones aren't available in Latest Dynatrace. Two separate concepts replace them:

  • Segments: Filter and group data in the UI. Segments don't restrict who can see what, because anyone with read permissions can pick any segment.
  • Record-level policy conditions: Control access. There is no management-zone attribute in Grail policies. To get a similar scoping effect, add a WHERE condition to a policy statement instead.

In Dynatrace Classic, you could also add tags to your frontend applications and use them in management zone rules and filters. In Latest Dynatrace, you recreate this with primary Grail tags (primary_tags.*). You add them to your RUM data at ingest with a DQL processor in OpenPipeline, deriving the value from frontend.name. You can then use the tags to define segments, route data, assign buckets, and create alerts. See Enrich RUM telemetry with primary Grail fields and tags.

What to do

  1. List each of your RUM management zones along with the apps/frontends its rules cover.

  2. Decide if you need access control or just filtering. For zones that only filtered data, build a segment per dimension, not per old zone. A zone like checkout_prod usually encodes two dimensions (app and stage) that become two separate, combinable segments instead of one. For zones that actually restricted access, continue with the next steps.

  3. Scope policies by application, most commonly with storage:frontend.name. For each group that had a zone restriction, write:

    ALLOW storage:user.events:read WHERE storage:frontend.name="checkout_app";
    ALLOW storage:user.sessions:read WHERE storage:frontend.name="checkout_app";

    For all fields that you can use in policy conditions, see Permission fields.

  4. For zones not based on applications (for example, tags or host groups), enrich the data with a dt.security_context value at the source and scope policies with WHERE storage:dt.security_context="<value>" instead. If many groups need similar conditions, use policy boundaries or templates to manage them at scale instead of repeating the WHERE clause per policy. See Configure advanced permissions with security context.

  5. Rebuild your groups with the scoped policies above plus the permissions from Permissions, replacing the old management-zone assignment.

For more guidance on segments, see Upgrade from management zones to segments.

Ready for more?

Once you have completed all steps for upgrading your permissions and segmentation configuration, continue with recreating measurements, analysis, and operations.

Related topics

  • Upgrade Real User Monitoring
  • RUM permissions
  • Role-based permissions (Dynatrace Classic)
  • Working with policies
  • Configure advanced permissions with security context
  • Upgrade from management zones to segments
  • Grant access to Settings
  • Management-zone rules (Dynatrace Classic)
  • Enrich RUM telemetry with primary Grail fields and tags
Related tags
Digital Experience