On this page:
Roles define a set of privileges that AppDynamics Controller users have within the AppDynamics managed environment. This is also called role-based access control, or RBAC.
The Controller UI enables you to apply permissions at a very fine-grained level. For example, you can grant permission to configure only a single application or a particular tier, or to access a particular feature of the UI, such as custom dashboards.
The Controller UI includes these preconfigured roles:
You cannot edit the predefined role permissions, however you can create new ones based on the existing roles, as described in the following section.
To view permissions, as an administrator or account owner in the Controller UI, click Settings > Administration from the gear icon menu and click the Roles tab. From the tab, you can create new roles and modify or delete custom roles.
You can clone predefined roles as a starting point for creating your own customized roles, but you should not assume the cloned roles have all of the permissions of the predefined role. In some cases, there may be hidden permissions, so you should add or remove permissions as needed for your customized role to ensure that you get the RBAC result you need.
After you have created a custom role, select it and configure permissions by clicking the tabs:
The following sections provide more information on the available permissions.
You can set custom role permissions in the Controller UI for all applications, for specific applications, and for some permissions, for specific tiers within an application.
Application permissions follow an inheritance model. There are three levels in the model listed here in order from highest (default) to lowest (tier-specific):
By default, each level inherits from the one above it, unless permissions are customized at a lower level. This mechanism enables you to grant access to groups or users for specific business applications in the Controller UI.
Customized permissions at a specific level override more general permissions. That is, tier-specific permissions take precedence over application-specific permissions and application-specific permissions override default permissions. Not all permissions can be customized at the tier-level.
Permissions that can be set for a role include the following:
To set product area or application level permissions, follow these steps:
For information on application permissions, see Application Permissions below.
Within specific and default permissions, granting a specific permission takes precedence over denying the same permission. This means that if a user is assigned two roles and one grants a permission and the second role denies it, the user will have permissions for the activity.
The following examples are designed to illustrate how overlapping permissions of different roles interact. The examples enable view, edit, delete permissions to applications as shown for two Groups. The last column shows the resulting permissions for a specific user with roles that are assigned to each group.
|Group 1||Group 2|
(view, edit delete all applications)
(view, edit delete application-1)
(view, edit delete all applications)
(view, edit delete application-1)
Result for example A - user has view, edit, and delete permissions to all applications, including application-1.
Result for example B - user has view, edit, and delete permissions to all applications, including application-1.
Result for example C - user has view, edit, and delete permissions to all applications, excluding application-1.
Custom dashboards are a good way to present selected metrics for a user who only needs a relatively narrow or focused view of the data. For example, an executive may only need a high-level view of system performance and activity. You can allow such users to view custom dashboards by assigning them to the built-in Custom Dashboard Viewer role. The permissions of this role are limited to viewing custom dashboards in the Controller UI.
As an alternative to using the Custom Dashboard Viewer role, you can share a custom dashboard. A shared dashboard is essentially public; anyone with the URL for a shared dashboard can access it, even users who are not logged in to the Controller UI. For more information, see Custom Dashboard Visibility and Permissions in Custom Dashboards.
You grant privileges to view, edit or delete a custom dashboard in the Custom Dashboards tab.
The default dashboard role applies if more specific permissions are not set for a custom dashboard or for new dashboards created later. Every dashboard inherits the default custom dashboard permissions unless you override them by configuring separate permissions for individual dashboards.
For example, you could have a custom dashboard called SalesDashboard and a custom role SalesRole, and another custom dashboard called FinanceDashboard and a custom role FinanceRole. The SalesRole could be configured to have permissions in the SalesDashboard but not in the FinanceDashboard or vice-versa.
Account-level permissions are general settings that apply account-wide across business applications, products, and multiple application instances for the same account. Most can be considered administration permissions. These include:
Create War Rooms: Can create (start) a war room. See Virtual War Room. War rooms are collaborative custom dashboards created in real time.
To ensure that your users have access to the full Analytics functionality they need, be sure to give them the view permission on the Default Application on the Applications tab. For more details on permissions related to Analytics data and functionality, see Analytics and Data Security.
To configure user permissions for Database Visibility functionality, navigate to the Applications tab. In the Database Monitoring dropdown menu, select Customized, then click the View box that appears. In the Databases tab, you can configure the permissions for custom roles. For each custom role, you can select which databases the user is allowed to view, edit, or delete. If you enable the Can View All Collectors permission for a custom role, the user for that role will be able to view all existing database collectors, as well as any new database collectors that are created.
Only users with Can View All Collectors and Can Edit All Collectors permissions can modify wait state filtering and remove query literals.
The following table lists the permissions that you can grant at the application level and tier levels, and those required to configure features such as EUM, Database Monitoring, and Analytics.
Asterisks (*) indicate permissions that should be considered sensitive for security and data privacy purposes. Carefully consider the security and data privacy policies of your organization before granting these permissions.
|Permission name||Activities enabled in the UI|
|Configure Transaction Detection*|
Create, edit, or delete transaction detection - can be at the tier level. (Transaction Detection Rules)
|View Sensitive Data*||New in 4.3.1. In combination with Configure Transaction Detection, use Live Preview and Business Transaction Discovery features to stream live data from your application.|
Configure Backend Detection
Create, edit, or delete backends - can be done at tier level.
|Configure Error Detection|
Create, edit, or delete error detection. (Error Detection)
|Configure Diagnostic Data Collectors*|
Create, edit, or delete diagnostic data collectors. (Data Collectors)
|Configure Call Graph Settings|
Create, edit, or delete JMX metrics. (Configure JMX Metrics from MBeans)
|Configure Memory Monitoring|
Configure which custom classes are tracked by Object Instance Tracking. (Object Instance Tracking for Java)
Note: to enable or disable Object Instance Tracking, you need the Configure Agent Properties permission.
|Configure Information Points*|
Create, edit, or delete information points (Information Points)
|Configure Health Rules|
Create, edit, or delete health rules (Configure Health Rules)
To create, edit, or delete email digests, a user must have the Configure Actions, Configure Health Rules, and Configure Policies permissions all enabled.
Create, edit, or delete policies. (Configure Policies)
|Configure Business Transactions|
|Start Diagnostic Sessions|
Start a diagnostic session. (Diagnostic Sessions)
Create, edit, or delete baselines. (Dynamic Baselines)
|Configure SQL Bind Variables*|
Turn on or off capture raw SQL (must have both Call Graph and SQL Bind on). (Call Graph Settings)
|Configure Agent Properties|
|Agent Advanced Operation|
|Set JMX MBean Attributes and Invoke Operations|
Edit MBean attributes or invoke actions on operations. (Monitor JMX)
|Configure Service Endpoints|
Create, edit, or delete service end points. (Service Endpoints)
|Configure Monitoring Level (Production/Deployment)|
Switch between production and development mode. (Development Level Monitoring)
|Configure 'My Dashboards' for Tiers and Nodes|
Create, edit or delete custom dashboards. (Create and Manage Custom Dashboards and Templates)
|Configure Server Visibility|
Can view all Servers tabs and windows and configure Service Availability Monitoring. (Service Availability Monitoring)
|View Server Visibility|
Can view all Servers tabs and windows. (Server Visibility)
Can show and hide fields in analytics data so that sensitive data can be restricted to proper roles and users. (Managing Field Visibility)
Can view the analytics API tab to create and manage API authentication keys. Whoever has this API permission has access to all data since they can use cURL with the access key and access all data.
Can create metrics from analytics searches. This permission controls which roles and users can create metrics from analytics searches. Once the metric exists, alerts can be set up in the usual way.
|Can Create a Search*|
Can create and save an analytics search. Can indicate view, edit, and delete permissions for each saved search. (Analytics and Data Security)
Can view, edit, delete a specific analytics saved search. (Analytics and Data Security)
Can view analytics transaction data from specific applications. (Analytics and Data Security)
Can view analytics data for specific log sources. (Analytics and Data Security)
|Browser Requests Permissions*|
Can view analytics data from Browser requests. (Analytics and Data Security)
|Mobile Requests Permissions*|
Can view analytics data from Mobile requests and crash reports. (Analytics and Data Security)
|Custom Analytics Events Permissions*||Can query custom analytics events data. Permissions can be granted to view data for all custom analytics events or on an event by event basis. (Analytics and Data Security)|