AppDynamics User Management Guide

• Model type: hybrid
• Description: AppDynamics uses a two-plane RBAC model. The Account Management Portal governs global company roles (Company Admin, License Admin, Support, Company User) that apply across all AppDynamics components. The Controller Tenant UI governs tenant-scoped RBAC with predefined roles (Account Owner, Administrator, Read-Only, DB Monitoring Administrator, Custom Dashboard Viewer) and custom roles. Permissions are organized at three levels: account-level, application-level (with inheritance down to tier-level), and custom dashboard-level. Editing a user in the Account Management Portal affects all components simultaneously; editing via the Controller Tenant UI affects that tenant only. When a user holds multiple roles, a grant in any role takes precedence over a deny in another role for the same permission.
• Custom roles: Yes
• Custom roles plan: Available on paid SaaS and on-premises deployments; requires Account Owner role or the 'Administration, Agents, Getting Started Wizard' permission to create custom roles.
• Granularity: Application-level, tier-level, custom dashboard-level, and account-level. Permissions can be scoped to individual business applications, specific tiers within an application, individual custom dashboards, and account-wide administrative functions. Predefined role permissions are not editable; custom roles can be cloned from predefined roles and modified.

1. Log in to the Account Management Portal at accounts.appdynamics.com as a Company Administrator or License Administrator.
2. Select your name in the top-right corner and click Account, then navigate to User Management in the left navigation panel.
3. Click the '+' Add User button in the action bar at the top of the user list.
4. Enter the user's email address (required). Optionally enter first name, last name, and other profile fields.
5. Select one or more Company Roles appropriate for the user (Company Admin, License Admin, Support). If no role is selected, the user defaults to Company User with very limited rights.
6. Click Save. The user is created with Pending status and receives a time-sensitive activation email.
7. Optionally, assign the user to one or more Controller Tenants or Observability Platform tenants from the Assign Tenants step.
8. Optionally, assign tenant-scoped roles from the Assign Tenant Roles step.
9. For Controller Tenant-scoped user creation (SaaS): Log in to the Controller Tenant UI as Account Owner or a user with Administration permission, navigate to Settings > Administration > Users, and create the user there. This affects that tenant only.

Required fields: Email address

Watch out for:

• A user email may only be associated with one AppDynamics company account. Attempting to add an email already registered to another company account produces an error and requires contacting AppDynamics support.
• Company Administrator roles are not available on self-service trials; only paid accounts can assign this role.
• The ability to assign certain roles is gated by the administrator's own role; greyed-out role options indicate insufficient permissions to assign that role.
• Newly created users have Pending status and no Tenant access until they complete email activation and an administrator explicitly adds them to a Tenant.
• Only ASCII characters are recommended for usernames and passwords due to browser incompatibilities.
• Account Owner and administrator roles cannot create or change user passwords for SaaS accounts; only the user can set their own password.
• Editing a user account through the Account Management Portal affects the user for all AppDynamics components simultaneously; editing through a Controller Tenant UI affects only that tenant.

• Can delete users: Yes
• Delete/deactivate behavior: Permanent deletion is supported (added September 2020) but only for users in Pending or Inactive (Disabled) status. Active users must first be set to Inactive before deletion. Deletion via the Account Management Portal is permanent and irreversible; the user receives an email notification that their account is no longer available. Deleting a user through a Controller Tenant UI does not delete the account globally - the user remains Active in the Account Management Portal and retains access to other tenants. Guest Users cannot be permanently deleted; they can only be removed from a specific tenant.

1. Log in to the Account Management Portal at accounts.appdynamics.com as a Company Administrator.
2. Navigate to User Management via the left navigation panel.
3. Select one or more users with Active status by clicking their row to enable the checkbox.
4. Click the 'X'-shaped Disable button in the action bar.
5. Click Disable on the confirmation dialog.
6. For bulk deactivation: select multiple users; the system processes the request asynchronously and sends a completion notification email to the administrator.
7. To permanently delete: after deactivation, select the now-Inactive user(s), click the trash-can Delete button, and confirm on the Delete User dialog.

Watch out for:

• Active users cannot be directly deleted; they must first be set to Inactive status, then deleted in a second step.
• Deleting a user through a Controller Tenant UI leaves the account Active in the Account Management Portal, preserving access to other tenants.
• Deletion is permanent and irreversible; the deleted user receives an automated email notification.
• Guest Users cannot be permanently deleted from the system; they can only be removed from individual Observability Platform tenants and re-added if needed.
• When a user is deleted through the Tenant UI, their account remains Active in the Account Management Portal, which may create a false impression that the user has been fully offboarded.
• Deactivating a user prevents login to all AppDynamics role-based components including all associated tenants, but the deactivation must be performed in the Account Management Portal for global effect.

• Where to check usage: Account Management Portal (accounts.appdynamics.com) > License Usage tab shows product usage by subscription. Programmatic access via REST API: GET /controller/licensing/v1/account/{accountId}/usage for account-level usage; GET /controller/licensing/v1/account/{accountId}/grouped-usage/application/by-id for per-application vCPU usage.
• How to identify unused seats: Use the Last Login column in the User Management UI (sortable, default sort is descending by last login) to identify users who have not recently authenticated. For license consumption, use the License API to query vCPU usage per host and application; hosts with agents in fallback mode (no Machine Agent installed) default to 4 vCPU consumption and may indicate misconfiguration rather than genuine usage.
• Billing notes: Licensing is per vCPU/CPU core, billed annually. IBL counts logical cores on the host; physical machine logical core count is used as vCPU count. If the Machine Agent is not installed, agents enter fallback mode and consume a default of 4 vCPUs (APM agents) or 4–12 vCPUs (DB agents) regardless of actual host size, which can inflate license consumption. License rules are provisioned at the account level and distributed within license rules. Licensing-related questions should be directed to the AppDynamics Account Manager or licensing-help@appdynamics.com.

There is no native SCIM provisioning - every app onboarding and offboarding requires manual steps in the Account Management Portal. SAML JIT handles user creation on first login but does not deactivate or delete users, so offboarding always requires a separate manual action.

Deactivation and deletion are also two distinct steps: active users must be disabled first, then deleted in a follow-up action - and deletion is irreversible.

The dual-plane model compounds this: removing a user from a Controller Tenant UI does not deactivate them globally. A user deleted at the tenant level remains active in the Portal and retains access to all other tenants, creating a real offboarding gap that requires explicit remediation.

The most consistent friction point reported is the dual-plane confusion - specifically, admins assuming a Tenant UI deletion constitutes full offboarding when it does not.

A second recurring issue is SAML group mapping misconfiguration: a wrong subdomain, base URL, or account name field in the IdP blocks SAML authentication entirely with limited diagnostic feedback.

User email addresses cannot be edited post-creation because the email is the primary system identifier. Changing a username requires deleting the account and recreating it from scratch.

IBL fallback mode - triggered when the Machine Agent is absent - silently inflates license consumption to a default of 4–12 vCPUs per agent regardless of actual host size.

Common complaints:

• No native SCIM provisioning for automated user lifecycle management; user creation and deactivation must be performed manually in the Account Management Portal or via SAML JIT (which only handles creation, not deactivation or deletion).
• Complex SAML group mapping configuration, particularly when mapping IdP groups to AppDynamics Controller Tenant roles; misconfiguration of subdomain/base URL or account name fields in the IdP prevents SAML authentication entirely.
• Dual-plane user management (Account Management Portal for global roles vs. Controller Tenant UI for tenant-scoped permissions) creates confusion: deleting a user in the Tenant UI does not deactivate them globally, leaving residual access to other tenants.
• User email addresses cannot be edited after account creation because the email is the primary system identifier; changing a username requires deleting the account and recreating it.
• Hidden permissions in predefined roles mean that cloning a predefined role to create a custom role may not replicate all permissions, requiring manual auditing and adjustment to achieve the intended RBAC result.
• IBL fallback mode (triggered when the Machine Agent is not installed) causes agents to consume default vCPU counts (4 or 12) regardless of actual host size, leading to unexpected license overages.
• Company Administrator role is unavailable on self-service trials, limiting user management capabilities for trial evaluations.

AppDynamics is appropriate for teams already invested in the Cisco/AppDynamics ecosystem who can absorb manual provisioning overhead. The two-plane RBAC model offers genuine granularity - application-level, tier-level, dashboard-level, and account-wide - but that granularity comes with operational complexity that scales poorly without tooling or process discipline.

Teams that require automated user lifecycle management across every app in their stack will find the absence of SCIM a meaningful constraint. SAML SSO is supported across major IdPs, but provisioning and deactivation remain out-of-band. On-premises deployments add further variability in API behavior and Controller version compatibility.

Bottom line

AppDynamics gives enterprise teams fine-grained RBAC across application, tier, and dashboard scopes, but the absence of SCIM and the split between the Account Management Portal and Controller Tenant UI means every app access change - provisioning, role updates, and especially offboarding - requires deliberate manual steps in the right plane.

Teams without a disciplined offboarding process face real residual-access risk, since tenant-level deletions do not propagate globally.

The platform suits organizations with dedicated APM administrators who can own that operational overhead; it is a poor fit for teams expecting IdP-driven lifecycle automation out of the box.