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:
- Account Owner: Can manage security settings (users, groups, roles), view and modify applications and dashboards, create action templates, configure email and SMS settings, view business flow and view the AppDynamics license. This role is also known as the account administrator.
- Administrator: Can view and modify components that change state, such as applications, business transactions, dashboards, and so on. Can view and edit all applications and all custom dashboards.
- Custom Dashboard Viewer: Can only view custom dashboards.
- Read Only User: Can view all applications but cannot edit any.
- Workflow Executor: Can execute workflows.
- DB Monitoring User: Can view the Database Monitoring UI. Cannot add, edit or delete database collectors.
- DB Monitoring Administrator: Can view the Database Monitoring UI and add, edit or delete database collectors.
- Server Visibility User: Can view Server Visibility UI. Can not configure Server Visibility features.
- Server Visibility Administrator: Can view the Server Visibility UI and configure Service Visibility features including Service Availability Monitoring.
- Analytics Administrator: Can view and grant access to analytics features, such as creating API keys, creating metrics, creating extracted fields, and granting access for viewing analytics data. The admin has the capability to control which roles have access to specific applications or log source types. Additionally, the Analytics Administrator is the only user who is in charge of saved searches. By creating different saved searches, the Analytics admin can provide different data access levels to analytics users. For more details, see Analytics and Data Security.
You cannot edit the predefined role permissions, however you can create new ones based on the existing roles, as described in the following section.
Viewing and Creating Roles
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:
- Account for account level permissions
- Applications for application-level permissions, including the default Analytics, Database, and Server Visibility Applications
- Analytics for analytics permissions including access to saved searches and all analytics data
- Custom Dashboards for custom dashboard permissions
- Databases for databases monitoring by Database Visibility
- Users and Groups with this Role - view and users or other roles to the selected role
The following sections provide more information on the available permissions.
Configuring Application 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):
- Default settings
- Application-wide settings
- Tier-specific settings
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:
- The Can Create Applications permission, which enables a users to create business, browser, and mobile applications.
- Default permissions (applying to all applications) and application level permissions including the following:
- View option, which allows users to see the corresponding application.
- Edit option, which can be used to enable all or a subset of the application permissions as default permissions for the role.
- Delete permission, which allows users to delete business, browser, and mobile applications (or tiers). Setting default delete permissions allows the user to delete all three artifacts from the application model.
To set product area or application level permissions, follow these steps:
- Choose Customized from the permissions menu for the application (replacing the default of Inherited from Default or Inherited from Application).
- Check View option and then Edit, as shown in the following figure:
- In the dialog box, choose the individual permissions for the product area, Database Monitoring, Analytics, application, or tier.
For information on application permissions, see Application Permissions below.
Overlapping Role Permissions Examples
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.
Configuring Custom Dashboard Permissions
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.
Configuring Account Permissions
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:
- Administer: Can edit users, groups, roles, and the authentication provider. Can view the license.
- Configure Email/SMS: Can edit email and SMS settings used by AppDynamics to send alerts. See Enable an Email Server and Notification Actions.
- Execute Workflows: See Cloud Auto-Scaling.
- Create or view HTTP Request Templates: See HTTP Request Actions and Templates.
- Create or view Email Templates: See Email Templates.
Create War Rooms: Can create (start) a war room. See Virtual War Room. War rooms are collaborative custom dashboards created in real time.
- View Business Flow: Can view all applications in a multi-business-application flow map, including those for which they are not granted explicit application permissions. However, this role does not grant permission to drill down to applications that they have no permission for. To drill into the downstream metrics and snapshots for the correlated application, the user must be a member of a role with view permissions to that business application. For more about cross application flow, see Cross Application Flow.
- Configure Scheduled Reports: Can create, delete, send, or update scheduled reports.
Configuring Analytics Permissions
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.
Configuring Database Visibility Permissions
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)|