Dynatrace User Management Guide

• Model type: hybrid
• Description: Dynatrace uses a hybrid model combining predefined roles (e.g., Environment Administrator, Viewer) with a policy-based access control layer. Policies are written in a proprietary policy language and can be applied at account or environment scope. Users are assigned to groups; groups receive roles and policies. Direct user-level role assignment is also supported but group-based assignment is recommended.
• Custom roles: Yes
• Custom roles plan: Enterprise (SaaS); policy management available on Enterprise tier with account-level IAM access.
• Granularity: Environment-level and account-level scoping. Policies can target specific entity types, settings schemas, API token scopes, and management zones. Management zones provide an additional data-access filtering layer on top of roles.

1. Navigate to https://myaccount.dynatrace.com and sign in as Account Owner or Account Administrator.
2. In the left navigation, select 'Identity & access management' → 'Users'.
3. Click 'Invite user'.
4. Enter the user's email address.
5. Optionally assign the user to one or more groups at invite time.
6. Click 'Send invitation'. The user receives an email invitation to activate their account.
7. Once the user accepts the invitation, they appear as 'Active' in the Users list.
8. To assign environment access, ensure the user is a member of a group that has the appropriate role or policy bound to the target environment.

Required fields: Email address

Watch out for:

• Users without group membership receive no environment access by default; they can log in but see no data.
• Invitation emails may be filtered as spam; users should check junk folders.
• If SSO is enforced, invited users must authenticate via the configured IdP; password-based login is disabled.
• Domain verification is required before enabling SCIM provisioning; manual invites still work without domain verification.
• Invited users count toward the account's user list immediately upon invitation, before acceptance.

• Can delete users: Yes
• Delete/deactivate behavior: This app exposes delete operations in its API documentation, but the admin-console path may present removal as deactivation, archiving, or deletion depending on tenant configuration. Confirm whether the UI action is reversible before treating removal as recoverable.

1. Navigate to https://myaccount.dynatrace.com → 'Identity & access management' → 'Users'.
2. Locate the user by name or email using the search field.
3. Click the user's row to open their profile.
4. To deactivate: click the action menu (three dots) and select 'Deactivate user'. The user's status changes to 'Inactive' and they can no longer log in.
5. To delete: click the action menu and select 'Delete user'. Confirm the deletion in the dialog. This action is irreversible.

Watch out for:

• API tokens created by a deleted user are NOT automatically revoked; administrators must manually audit and revoke orphaned tokens via Settings → Integration → Dynatrace API → API tokens.
• Deleting a user is irreversible; the user must be re-invited if access needs to be restored.
• If SCIM provisioning is active, user deactivation/deletion should be managed in the IdP to avoid sync conflicts; manual deletion in Dynatrace may be overridden on the next SCIM sync cycle.
• The Account Owner cannot be deleted or deactivated by other administrators.

• Where to check usage: Dynatrace Account Management (https://myaccount.dynatrace.com) → 'Subscription' → 'Usage' to view DPS consumption by environment and service type.
• How to identify unused seats: Review the 'Usage' dashboard in Account Management to identify environments with zero or minimal consumption. Within environments, use Dynatrace's built-in 'License usage' app (Settings → Subscription & licensing → License usage) to see per-host and per-service consumption. Users themselves do not consume a fixed seat license; unused user accounts do not directly incur charges.
• Billing notes: Dynatrace uses a consumption-based Dynatrace Platform Subscription (DPS) model. There is no per-user seat fee for standard access. Costs are driven by monitored host hours, log volume, session counts, and other metered resources. Enterprise contracts typically include a committed DPS spend with overage rates. A minimum commitment of approximately $2,000/month is typical for enterprise contracts. The 15-day free trial provides limited DPS credits.

Dynatrace runs on a consumption-based Dynatrace Platform Subscription (DPS) model - there is no per-user seat fee for standard access. Costs are driven by monitored host hours, log volume ingested, and session counts, not headcount.

That said, SCIM provisioning and account-level IAM controls require the SaaS Enterprise tier; teams on lower tiers must manage users entirely through manual invite and group assignment workflows.

The most consistent friction point reported by administrators is the two-layer access model: a user can hold an Account Administrator role yet see a completely blank environment because no group with environment-level permissions was assigned.

New invitees land in PENDING status and, without group membership, log in successfully but see no data - a silent failure that generates support tickets.

A second recurring issue is orphaned API tokens: deleting a user does not revoke tokens they created, requiring a separate manual audit under Settings → Integration → Dynatrace API → API tokens.

The proprietary policy language for custom roles adds a third layer of complexity; malformed policy statements fail silently rather than returning actionable errors.

Common complaints:

• Users report that new invitees with no group assignment can log in successfully but see a blank environment with no data, causing confusion about whether the invitation worked correctly.
• Administrators report difficulty understanding the distinction between account-level roles and environment-level roles, leading to users having account admin access but no environment data access.
• The proprietary Dynatrace policy language for custom roles has a steep learning curve; errors in policy statements do not always produce clear error messages.
• API tokens created by deleted users are not automatically revoked, creating a security gap that requires manual auditing.
• Community members report that SCIM sync conflicts can occur when users are manually modified in Dynatrace while SCIM provisioning is active, requiring re-sync or IdP-side corrections.
• Some users report that the Account Owner transfer process requires contacting Dynatrace support rather than being self-service, causing delays during organizational changes.
• The lack of a CSV bulk import for users is noted as a limitation for organizations onboarding large teams without an IdP SCIM setup.

Manual user management in Dynatrace is workable for small, stable teams but becomes error-prone at scale. Every app and environment requires its own group-policy binding, so onboarding a single user across multiple environments means multiple group assignments - each one a potential miss.

Teams managing more than a handful of environments, or with frequent onboarding and offboarding, should prioritize SCIM provisioning via Okta or Microsoft Entra ID to keep the IdP as the source of truth.

Manual management is a reasonable interim approach only if domain verification and SSO configuration are not yet complete, since both are prerequisites for SCIM.

Bottom line

Dynatrace's access model rewards teams that invest in group structure upfront: get groups, roles, and policies right once, and every subsequent user invite is a single group assignment.

Skip that foundation and every onboarding becomes a multi-step, error-prone process with silent failures when permissions are misconfigured.

The Account Owner transfer limitation - requiring a support ticket rather than a self-service UI action - is a meaningful operational risk worth flagging to IT leadership before an organizational change forces the issue.