> ## Documentation Index
> Fetch the complete documentation index at: https://docs.oleria.com/llms.txt
> Use this file to discover all available pages before exploring further.

# AppDynamics

> Connect your AppDynamics SaaS Controller to Oleria to discover its users, groups, roles, and API clients, and the Controller audit history.

Connect AppDynamics to Oleria to see who and what can act on your AppDynamics SaaS Controller: its users, the groups and roles that grant their access, the API clients that call the Controller's APIs, and what they do with that access. Oleria connects with an AppDynamics API client, and can also change a user's roles and groups, or remove all of a user's access.

## What Oleria discovers

Once connected, Oleria continuously discovers and maps the following from your Controller:

* **Users** - every Controller user, whether local, SAML, or LDAP, with name, email, and the roles assigned to them directly. Users who hold the **Account Owner** or **Administrator** role, directly or through a group, are marked as administrators. SAML users show single sign-on (SSO) as required. Local and LDAP users show SSO as not configured and password sign-in, and are marked as having API access, because AppDynamics lets them call its APIs with their username and password.
* **Last activity and password changes** - Oleria takes each user's last activity, and last password change or reset, from the Controller audit history (see [Known limitations](#known-limitations)). A user with no recent activity shows no last activity. Token requests by an API client that shares a user's name don't count as that user's activity.
* **Groups** - every group, with its description. Groups mapped from SAML or LDAP are marked as synced from your identity provider. Groups created in the Controller are marked as custom.
* **Roles** - every role, with its description and a summary of its permissions. AppDynamics' predefined roles are marked as standard roles, and all others as custom roles.
* **Memberships** - which users belong to which groups, which roles each user and API client holds directly, and which roles each group grants. A user's effective access is their direct roles plus the roles of every group they belong to.
* **Non-human identities (NHIs):**

  | Identity | Shown as |
  | :- | :- |
  | API clients | Service account, with its roles, description, last activity, and, when AppDynamics reports them, its creation date and the user who created it |

  Each API client's client secret also appears as a credential, linked to its API client. A listed API client's secret is always active and carries all of the client's roles, so it's shown with full authority. AppDynamics doesn't report when a secret expires, was last used, or was last rotated. When AppDynamics reports who created an API client, and that user is discovered, the user is shown as the client's owner. The API client this integration connects as is marked as Oleria's connection.
* **Activity** - events from the Controller audit history:

  * sign-ins, failed sign-ins, and sign-outs;
  * token requests made with an API client's secret;
  * roles assigned to or removed from users and groups, and permissions added to or removed from roles;
  * users added to or removed from groups;
  * password changes and resets, email changes, and re-enabled accounts;
  * SAML and LDAP configuration changes;
  * objects created, updated, or deleted, and application configuration, log level, and anomaly detection changes.

  Oleria keeps every other audit event too, under its AppDynamics action name. Events made with an API client are attributed to that API client and its client secret. Events whose user Oleria can't match to a discovered user or API client aren't attributed to an account. Events about users, groups, and roles are linked to them. Events about other Controller objects, such as applications, are linked to the Controller itself and keep the object's type and name. Oleria drops the sign-ins, sign-outs, and token requests of this integration's own API client, and marks changes Oleria makes as Oleria activity.

Oleria refreshes this data on its [regular sync schedule](/integrations/overview#sync-model).

<Note>
  This integration covers identities, groups, roles, and activity. It doesn't inventory business applications, tiers, nodes, business transactions, dashboards, or health rules, so Oleria doesn't populate resource-level Access Graph or Access Inventory data for AppDynamics. A role's application-level permissions appear only in its permission summary.
</Note>

## Prerequisites

* An AppDynamics SaaS Controller, at an address such as `https://acme.saas.appdynamics.com`. On-premises Controllers aren't supported.
* An AppDynamics user with the **Account Owner** role, to create the API client and assign its role.
* Admin access on the Oleria platform to add a new integration.

Each integration connects one Controller. If you have more than one Controller, add an integration for each. See [Multi-instance support](/integrations/overview#multi-instance-support).

<Warning>
  The API client needs the **Account Owner** role, or a custom role with the account permission **Administration, Agents, Getting Started Wizard**. AppDynamics has no narrower permission that can read users, groups, and roles, and this permission also lets the API client change them. Oleria uses the same API client for [remediation actions](#remediation-actions), so there's no separate read-only credential. Store the client secret securely.
</Warning>

## Create an API client in AppDynamics

<Steps>
  <Step title="Open API clients">
    Sign in to your Controller as an Account Owner and go to **Settings** > **Administration** > **API Clients**.
  </Step>

  <Step title="Create the API client">
    Create an API client for Oleria. Its name can't contain `@`, `/`, or spaces, because Oleria signs in as `<API client name>@<account name>`.
  </Step>

  <Step title="Generate a client secret">
    Generate a client secret for the API client and copy it. You enter it in Oleria later.
  </Step>

  <Step title="Assign a role">
    Assign the API client one of these roles, then save it:

    * the **Account Owner** role (recommended);
    * a custom role with the account permission **Administration, Agents, Getting Started Wizard**. See [Known limitations](#known-limitations) for what it may not read.
  </Step>

  <Step title="Find your account name">
    Go to **Settings** > **License** > **Account** and note your account name. It's often the sub-domain of your Controller URL, such as `acme` in `https://acme.saas.appdynamics.com`.
  </Step>
</Steps>

<Note>
  AppDynamics tokens expire after the API client's default token expiration. Oleria requests a new token before each one expires, so you can keep the default.
</Note>

## Connect AppDynamics to Oleria

<Steps>
  <Step title="Open the integration">
    Go to your Oleria workspace, select **Integrations** -> select **AppDynamics**.
  </Step>

  <Step title="Complete the connection form">
    Provide the following:

    | Field | Notes |
    | :- | :- |
    | Controller URL | Required. Your SaaS Controller URL, for example `https://acme.saas.appdynamics.com`. It must use `https`, and its host must be `appdynamics.com` or end in `.appdynamics.com`. Oleria ignores anything after the host name. |
    | Account name | Required. Your account name, from **Settings** > **License** > **Account** in the Controller. It can't contain `@`, `/`, or spaces. |
    | API client name | Required. The name of the API client you created. It can't contain `@`, `/`, or spaces. |
    | Client secret | Required. The client secret you generated for that API client. |
  </Step>

  <Step title="Confirm the connection">
    Select **Authenticate**. Before it saves anything, Oleria:

    * requests a token for the API client, as `<API client name>@<account name>`;
    * reads the Controller's roles, to confirm the API client can read users, groups, and roles;
    * reads the AppDynamics account's ID and name, to identify the connected account. If AppDynamics doesn't return them, Oleria uses the Controller host and account name instead.

    Find the newly connected Controller on the **Connected** tab of your Oleria **Integrations** page.
  </Step>
</Steps>

If **Authenticate** fails, the message says what's wrong:

* **Controller URL must be an https\://\*.appdynamics.com SaaS Controller URL** - enter your SaaS Controller URL, such as `https://acme.saas.appdynamics.com`. On-premises Controllers aren't supported.
* **the Controller URL failed validation** - Oleria couldn't look up the Controller's host name, or it points to an address Oleria won't connect to. Check the URL for typos, such as a mistyped tenant sub-domain.
* **Account name must not contain @, / or spaces** or **API client name must not contain @, / or spaces** - check the name you entered.
* **AppDynamics rejected the API client credentials** - check the API client name, account name, and client secret. If you've lost the secret, generate a new one.
* **The API client lacks the Account Owner role** - assign the API client the **Account Owner** role, or a custom role with **Administration, Agents, Getting Started Wizard**.
* **The Controller URL does not serve the AppDynamics RBAC API** - check that the URL is your SaaS Controller's address.
* **reading AppDynamics roles** - the Controller didn't respond or was busy. Try again in a few minutes.

## Edit the integration

When you edit the integration, you can change **API client name** and **Client secret**. **Controller URL** and **Account name** can't be changed, because they identify the connected account.

* Leave **Client secret** blank to keep the stored secret. If you change **API client name**, enter that API client's secret too, because each API client has its own secret.

Select **Update** to save. Oleria runs the same checks as **Authenticate**. If the new credentials belong to a different AppDynamics account, Oleria refuses them, and the message says **these credentials belong to a different AppDynamics account than the connection**. To connect a different account or Controller, add a new integration. If AppDynamics doesn't return the account's ID, so Oleria can't check this, the message says **AppDynamics did not return the account id**: try again in a few minutes.

## Verify the integration

Confirm the Controller appears on the **Connected** tab of your Oleria **Integrations** page with a status of **Healthy**. After the first sync completes, review the discovered users, groups, roles, API clients, and activity in your Oleria workspace.

In the integration's **Capabilities and operation readiness** section, **Read users**, **Read groups**, and **Read roles** show **Available**. If one shows **Needs permission**, check that the API client still has the **Account Owner** role, or a custom role with **Administration, Agents, Getting Started Wizard**.

If the sync is marked as partially completed, the API client couldn't read the API client list or the audit history, so API clients or activity are missing. See [Known limitations](#known-limitations).

## Remediation actions

Oleria can take these actions in AppDynamics. They're available as soon as you connect. AppDynamics has no read-only credential, so you can't connect without them (see the warning in [Prerequisites](#prerequisites)).

| Action | What it does | Revert |
| :- | :- | :- |
| Disable user accounts | Removes all of the user's directly assigned roles and all of their group memberships. AppDynamics has no way to disable a user, so this is how Oleria removes their access. The user stays in the Controller. | Supported - assigns the removed roles and adds the user back to the removed groups. Roles and groups that no longer exist are skipped. |
| Add user to role | Assigns a role directly to the user. | Supported - removes the role. |
| Remove user from role | Removes a role assigned directly to the user. | Supported - assigns the role again. |
| Add user to group | Adds the user to a group. | Supported - removes the user from the group. |
| Remove user from group | Removes the user from a group. | Supported - adds the user back to the group. |
| Disable NHI accounts | Not supported for API clients. AppDynamics API clients have no disable state, and deleting one can't be undone. | Not applicable. |
| Delete user | Deletes the user from the Controller. The action's result records the user's name, email, roles, and groups. | Not supported. Deleting a user can't be undone in AppDynamics. |
| Create user | Creates a local AppDynamics user with the username, display name, email, and password you provide, or a password Oleria generates. It can also add the user to groups, by group ID or exact name. | Supported - deletes the user the action created. |
| Create group | Creates a local AppDynamics group with the name you provide. | Supported - deletes the group the action created, if it has no members. |

<Note>
  The **Remediations** page offers **Revert** only for **Disable user accounts** and **Remove user from group**. The integration supports the other reverts in this table, but the Remediations page doesn't offer them yet. Oleria can revert only an action that completed or partially completed, never one that failed.
</Note>

<Warning>
  **Disable user accounts** removes every role and group the user has, so the user can no longer do anything in the Controller. A user with no role has no functionality in AppDynamics. To restore the user's access, revert the action.

  **Delete user** can't be undone. A user created again gets a new ID, users from SAML or LDAP can't be created again by Oleria, and custom dashboards, shares, and reports the user owned stop working. To remove a user's access but keep the user, use **Disable user accounts** instead.
</Warning>

Keep these limits in mind when you use these actions:

* Oleria reads the user before it makes a change. If the user already has, or doesn't have, the role or group, Oleria makes no change, and reverting the action makes no change either.
* After AppDynamics accepts a change, Oleria reads the user again to check it. If that read fails, the action succeeds and is marked unverified, and you can revert it. If the read shows the user's roles or groups don't match the change, the action fails and can't be reverted: check the user in the Controller.
* If AppDynamics answers a change with a server error, Oleria sends it again. If it still fails, or AppDynamics doesn't answer, Oleria reads the user again, up to three times. If the change is there, the action succeeds but is marked unconfirmed, because Oleria can't tell that the change was its own. If it isn't, the action fails and nothing changed.
* Oleria won't revert an unconfirmed action. Check the user's roles and groups in the Controller and correct them there. This includes a removal in **Disable user accounts** that AppDynamics didn't answer but that is in place when Oleria checks again: it's listed as unconfirmed, and reverting the action doesn't restore it.
* Reverting an action changes only what the action changed. If the role or group is already back to how it was, or the user, role, or group no longer exists, the revert makes no change and says why.
* **Remove user from role** removes only a role assigned directly to the user. If the user has the role only through a group, Oleria refuses and names the group. Use **Remove user from group** instead. If the user has the role both directly and through a group, Oleria removes the direct assignment and the action succeeds, but the user keeps the role through that group.
* If **Disable user accounts** fails partway, the action fails and reports which roles and groups it removed. Oleria can't revert a failed action, so use that list to re-add the removed roles and groups in the Controller. If a revert fails partway, it reports which roles and groups it restored.
* Oleria refuses any change that would leave the Controller with no user holding the **Account Owner** role, directly or through a group. API clients with the **Account Owner** role don't count, because they can't sign in to the Controller. If Oleria can't read the roles, groups, or users it needs to check this, it refuses the change. If it can't find the **Account Owner** role, it refuses any change that would leave the user with no role that could be it, directly or through a group. A role could be the Account Owner role unless it's one of AppDynamics' other predefined roles. It checks again immediately before each change. If two changes that each remove a different Account Owner run at the same moment, both can pass the check, so remove Account Owners one at a time.
* Oleria refuses to change API clients, including the API client this integration connects as. Change an API client's roles in the Controller.
* For SAML users, roles and groups mapped from SAML attributes may be applied again the next time the user signs in.
* If AppDynamics refuses **Add user to group** or **Remove user from group** for a group mapped from SAML or LDAP, the action fails and reports that the group is managed by that provider. During **Disable user accounts**, the same refusal stops the action: partway if it already removed something, otherwise before it changes anything.
* **Delete user** follows the same Account Owner rule as the other actions: Oleria refuses to delete the last user with the **Account Owner** role. It also refuses to delete an API client or a user that doesn't exist.
* If AppDynamics doesn't answer a delete, or answers with a server error, Oleria sends it again, up to three times in all. If the user is gone by the time Oleria sends it again, the earlier attempt deleted it, so the action succeeds and still records who the user was. Reverting **Create user** or **Create group** deletes the same way.
* **Create user** creates only local users, because AppDynamics creates users from SAML or LDAP when they first sign in. AppDynamics requires a password for a local user, so the action needs a password or needs Oleria to generate one. Oleria doesn't return a generated password, so reset the password in the Controller before the user signs in. AppDynamics has no inactive state, so the new user can sign in as soon as it exists, even when the request asks for an inactive user or doesn't say. The action's result notes this. With no role or group, the user has no functionality. If AppDynamics refuses the email address, Oleria creates the user without one, and the action's result says so. Add the email address in the Controller.
* If a user or group with the same name already exists, ignoring upper and lower case, **Create user** and **Create group** fail and change nothing.
* If adding the new user to a role or group fails, the action fails but the user still exists. Delete the user in the Controller, or run **Delete user** on it.
* If AppDynamics doesn't answer a create, Oleria doesn't send it again. It checks for the name instead. If the user or group now exists, the action fails and can't be reverted, because Oleria can't tell it created it. Check it in the Controller and delete it there if needed.
* The result of **Create user** shows whether any group it added grants the **Account Owner** or **Administrator** role.
* Reverting **Create user** deletes only the user the action created. Oleria refuses if that user now has a different name, or if it has since become the last user with the **Account Owner** role.
* Reverting **Create group** deletes the group only if it has no members. If anyone was added to it, Oleria refuses. Remove the members first, then revert again.
* Oleria can't assign roles to existing groups or update users and groups.

## Known limitations

* **SaaS Controllers only.** Oleria connects only to Controllers whose host is `appdynamics.com` or ends in `.appdynamics.com`, over `https` on port 443. On-premises Controllers aren't supported.
* **No user status.** AppDynamics doesn't report whether a user is deactivated or locked, so every listed user shows as enabled. A user deactivated in the Accounts Management Portal shows as enabled until they're removed from the Controller.
* **No MFA or sign-in policy.** AppDynamics doesn't report multi-factor authentication (MFA) or its authentication provider settings, so MFA and the Controller's sign-in requirements show as unavailable. Oleria also doesn't report when a user was created.
* **30 days of history.** When you connect, Oleria reads the last 30 days of the Controller audit history, and activity doesn't go back further. Last activity and last password change start from those 30 days. After that, each sync reads the history since the previous one, and Oleria keeps the most recent date it has seen. On a Controller with a very busy audit history, Oleria may read less than 30 days for last activity and last password change. Audit events don't include an IP address.
* **Custom administrator roles.** Only the predefined **Account Owner** and **Administrator** roles mark a user or API client as an administrator. A custom role with account administration permissions doesn't.
* **API clients come from an undocumented interface.** AppDynamics doesn't document an API that lists API clients, so Oleria reads them the same way the Controller's own interface does. If AppDynamics refuses that read or changes it, Oleria skips API clients and their secrets, and the rest of the sync continues. If the read fails temporarily, for example with a server error or a timeout, Oleria marks the sync as failed instead of skipping API clients, and reads them again on the next attempt. Activity still syncs, but events made with API clients aren't attributed to them on that sync. The same applies if the API client can't read the audit history: Oleria skips activity and keeps syncing everything else. A custom role with **Administration, Agents, Getting Started Wizard** may not be able to read API clients or the audit history; the **Account Owner** role is the most reliable way to avoid both.
* **Other credentials.** Oleria doesn't discover tokens generated with an API client's secret, temporary access tokens, account or license access keys, or analytics API keys. AppDynamics can't list tokens, and the keys aren't inventoried.
* **No Accounts Management Portal.** Oleria reads the Controller only. Company and license administrators in the Accounts Management Portal appear only if they're also users of the Controller.
* **No AI agents.** AppDynamics agents are monitoring software, not AI agents, so none appear.
* **Large Controllers.** AppDynamics returns each user, group, and role's details one at a time, so the first sync of a Controller with thousands of users can take a while.

## Contact us

For questions about this integration, contact us at [support@oleria.com](mailto:support@oleria.com).


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.