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 Monitoring User: Can view Server Monitoring UI. Can not configure Server Monitoring features.
- Server Monitoring Administrator: Can view the Server Monitoring UI and configure Service Monitoring 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 Roles tab, users with the Account Owner role or the Administer users, groups, roles ...permission can create, modify, or delete custom roles in the Controller UI. A common strategy for designing roles is to create a role with the minimum permissions allowable for all users, such as view permissions. Then you can create roles that use customizations of that minimum permission role to give additional, explicit permissions to a specific feature or business application.
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 Application
- Analytics for analytics permissions including access to saved searches and all analytics data
- Custom Dashboards for custom dashboards and War Room permissions
- Users and Groups with this Role - view and users or other roles to the selected role
The following sections provide more information on these permissions.
Configuring Application Permissions
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 permissions
- Application-wide permissions
- Tier-specific permissions
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.
General permissions include the following:
- The Can Create Applications permission controls users' ability to create business applications.
- The Delete permission allows users to delete business application, tiers, or nodes. Setting global delete permissions allows the user to delete all three artifacts from the business application model.
- The View option allows users to see the corresponding artifact in the Controller.
To set product area or business application level permissions, follow these steps:
- Choose Customized from the permissions menu (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, business 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 and War Room 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. War rooms are collaborative custom dashboards created in real time.
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 or war room in the Custom Dashboard and War Room Permissions 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 Configure the 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.
- 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.
- View Scheduled Reports: Can view 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.
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. (Business Transaction Detection)
Configure Backend Detection
Create, edit, or delete backends - can be done at tier level.
|Configure Error Detection|
Create, edit, or delete error detection. (Configure Error Detection)
|Configure Diagnostic Data Collectors*|
Create, edit, or delete diagnostic data collectors. (Collecting Application Data)
|Configure Call Graph Settings|
Create, edit, or delete JMX metrics. (Configure JMX Metrics from MBeans)
|Configure Memory Monitoring|
|Configure Database Monitoring|
|View Database Monitoring|
Can view all Database Monitoring windows (Monitor Databases and Database Servers)
|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. (Using 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). (Configure Call Graphs)
|Configure Agent Properties|
|Agent Advanced Operation|
|Set JMX MBean Attributes and Invoke Operations|
Edit MBean attributes or invoke actions on operations. (Monitor JMX MBeans)
|Configure Service Endpoints|
Create, edit, or delete service end points. (Service Endpoints)
|Configure Monitoring Level (Production/Deployment)|
Switch between production and development mode. (Monitor Development Environments)
|Configure 'My Dashboards' for Tiers and Nodes|
Create, edit or delete custom dashboards. (Create and Manage Custom Dashboards and Templates)
|Configure Server Monitoring|
Can view all Servers tabs and windows and configure Service Availability Monitoring. (Server Monitoring)
|View Server Monitoring|
Can view all Servers tabs and windows. (Server Monitoring)
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)|