Set Up Dynatrace Multi-Tenant Environments for Isolation (2026)

Dynatrace’s multi-tenant environments are designed for maximum isolation, meaning your data and configurations are kept strictly separate from other tenants, even though they might share underlying infrastructure.

Here’s how you can set up and manage these isolated environments:

The Problem: Sharing Without Touching

Imagine a large enterprise with many distinct business units, each needing its own monitoring setup within a single Dynatrace instance. They want the cost-efficiency of a shared platform but absolutely need to prevent Unit A from seeing Unit B’s sensitive application data or accidentally altering its monitoring configuration. This is the core problem Dynatrace multi-tenancy solves.

How it Works: The Tenant ID is King

At its heart, Dynatrace uses a "tenant ID" to segment everything. When data comes in from an agent, it’s tagged with the tenant ID of the environment it belongs to. All subsequent processing, storage, and access control are then filtered by this tenant ID. This applies to metrics, traces, logs, user sessions, configurations, and even user permissions.

Setting Up for Isolation

1. Environment Creation: When you first set up a Dynatrace environment (or request a new one from your SaaS provider), it’s automatically assigned a unique tenant ID. This is the foundational isolation layer. You don’t typically "set up" the tenant ID itself; it’s provisioned.

2. User and Group Management: This is where you enforce logical isolation within an environment.

   • Role-Based Access Control (RBAC): Dynatrace has a robust RBAC system. You define roles (e.g., "App A Admin," "App B Viewer") and assign specific permissions to these roles.
   • Environment Permissions: Crucially, you can grant users or groups access to specific environments only.
     • Example: Create a group "AppA_Admins". Assign them the "Environment administrator" role but restrict their access to only the "App A Production" environment.
     • Command/UI: In the Dynatrace UI, navigate to Settings > User management and security > User groups. Create a new group, assign roles, and under "Environment permissions," select only the environments this group should see.

3. Data Privacy Controls:

   • Data Masking: For sensitive data (like PII in user sessions or logs), Dynatrace offers data masking capabilities. You can configure rules to automatically mask or filter out specific patterns.
   • Example: Mask all credit card numbers found in user session details.
   • Command/UI: Go to Settings > Data privacy and retention > Data masking. Define rules based on regular expressions.

4. API Token Scopes: When users or automated systems interact with the Dynatrace API, their API tokens must also have scoped permissions.

   • Example: An API token used for automated deployment checks for "App B Staging" should only have read permissions for that specific environment and not be able to modify anything.
   • Command/UI: Navigate to Settings > User management and security > API tokens. When creating a token, under "Token scope," select "Custom" and then choose the specific environments and operations allowed.

A Real-World Scenario: Two Teams, One Dynatrace Instance

Let’s say you have "Team Alpha" monitoring their e-commerce platform and "Team Beta" monitoring their internal HR system. Both are on the same Dynatrace SaaS instance.

• Environment A: "E-commerce Production" (Tenant ID: abc123def456)
• Environment B: "HR Internal" (Tenant ID: ghi789jkl012)

Setup:

1. Users:

   • Create user group "Alpha_Engineers". Assign them the "Full environment access" role, but under "Environment permissions," select only "E-commerce Production."
   • Create user group "Beta_Analysts". Assign them the "Viewer" role, and under "Environment permissions," select only "HR Internal."

2. Result: An engineer in "Alpha_Engineers" can log in, see all data for "E-commerce Production," deploy agents there, change alerting rules, etc. However, when they look at the environment dropdown, "HR Internal" will be greyed out or simply not appear. Conversely, a "Beta_Analyst" can see everything in "HR Internal" but has no visibility into "E-commerce Production."

The Nuance: Shared Configuration vs. Tenant Isolation

While data and most configurations are tenant-isolated, some settings might be at the instance level, shared across all tenants. These are typically global settings like Dynatrace’s own security policies, licensing information, or global integrations that don’t inherently contain tenant-specific data. It’s crucial to understand which settings are global versus tenant-specific. Most operational configurations (alerting profiles, dashboards, synthetic monitors, OneAgent configurations) are strictly tenant-isolated.

The Next Hurdle: Cross-Environment Analysis

Once you have multiple environments properly isolated, the next challenge often becomes correlating events or performance across these separate tenants for high-level reporting or troubleshooting dependencies that span different business units.