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

# Adobe

*Lumos has 2 versions of the Adobe integration. Check the Domain ID under your Lumos domain.* `adobe_ics `*means a connection created **after August 2025** (this article's main path).* `adobe.com `*means the archived pre-August-2025 connection, with differences noted inline. Both connect to the Adobe User Management API with the same credentials.*

## After this article

You will be able to connect Adobe to Lumos to sync users, user groups, and product profiles. You can also provision and deprovision Adobe access, including reclaiming licenses during offboarding.

## Capabilities

| Functionality | Type | Sync | Provision | Description |
| :- | :- | :- | :- | :- |
| Users | Account | Yes | Yes | User account records |
| Groups | Permission | Yes | Yes | Adobe user group membership |
| Product Profiles | Permission | Yes | Yes | Product profiles (the product licenses a user can access) |

| AppStore | Offboarding | Access Reviews | License Management |
| :- | :- | :- | :- |
| Yes | Yes | Yes | Yes |

| Deprovisioning Action | Type | Description |
| :- | :- | :- |
| Deactivate | User | Deactivates the user in Adobe, removing them from product profiles and reclaiming licenses |
| Delete | User | Deletes the user from Adobe |

**Create Account note:** if the `AdobeAccountIdType` field is left blank, Lumos defaults to **Enterprise ID**. For a Federated ID, enter `"Federated ID"` for `AdobeAccountIdType` and a 2-letter `Country` code (e.g. `"US"`). Hardcoded string values need quotes.

**Pre-August-2025 (**`adobe.com`**) differences:** user statuses map active → Active, disabled/locked → Suspended, removed → Deprovisioned. Its two offboarding actions are **Suspend** (removes the user from all product profiles and user groups via `remove: all`, reversible, does not reclaim a license) and **Deprovision** (removes the user from the Adobe organization via `removeFromOrg` with `deleteAccount: false`, which reclaims the license). Both mark the Lumos account status Deprovisioned.

## Required plan and roles

* **Adobe plan:** the **Adobe Enterprise Tier** is required.
* **Adobe role:** your Adobe user needs access to both the **Admin Console** and the **Developer Console**.
* **Scope:** `user_management_sdk`, which grants read and write for user management in Adobe Admin (the connector authenticates with `openid AdobeID user_management_sdk`).
* **Permission scoping:** a read-only connection isn't possible. Adobe's OAuth implementation exposes only this single user-management scope, and it grants both read and write.

## Read-only access vs provisioning

**Is read-only possible?** No. Adobe's OAuth implementation exposes a single scope, `user_management_sdk`, for user management, and that scope grants read and write together. Adobe does not offer a narrower read-only scope.

**What full provisioning requires.** An OAuth Server-to-Server credential (Client ID, Client Secret, Organization ID) created in the Adobe Developer Console under the User Management API, on an Adobe Enterprise Tier account with Admin and Developer Console access. Follow the steps below to connect. Provisioning covers user create, deactivate (with license reclaim), and delete.

**Watch out for.** Because the one scope grants both read and write, there is no way to connect Adobe in a read-only mode, every connection can create, deactivate, and delete users. Deactivate keeps the account in your Adobe org without freeing the license, only Delete returns the seat to your pool. If Adobe access flows from an IdP group, removing it in Adobe Admin Console alone does not stick, since the group rule re-adds it on the next sync.

## Instructions

**Phase 1: Create credentials in Adobe**

1. Verify your domain in the Adobe Admin Console under **Settings → Domains** (click **Add Domains** and follow the prompts until the domain shows **Active**, and skip if already verified).
2. In the Adobe Developer Console, click **Create new project**, then **Add API**. Scroll to **User Management API**, click **Next**, and choose **OAuth Server-to-Server** authentication.
3. Under **Credentials**, open the **OAuth Server-to-Server** tab and copy the **Client ID**, **Client Secret**, and **Organization ID**.

**Phase 2: Connect in Lumos**

1. Go to your Lumos integrations and click the **Adobe** tile (reconnect an existing card or add a new one).
2. Choose the **OAuth** option in the dropdown.
3. Enter the **Organization ID**, **Client ID**, and **Client Secret** from Adobe.
4. Click **Connect Adobe**.

## API Endpoints Used

<Note>
  The API endpoints this integration uses are available to logged-in Lumos customers. [Log in](/login) to view them.
</Note>

## Troubleshooting

**"Lumos has not been granted sufficient scopes to integrate with Adobe"**: The credentials your company created don't permit Lumos to retrieve user records. Recreate the API credentials following Phase 1 (User Management API + OAuth Server-to-Server) and reconnect the integration.

**Lumos shows Adobe accounts that don't exist in Adobe**: Lumos marks a user Deprovisioned when it previously saw an account that Adobe's API no longer returns, meaning the user was removed from your Adobe organization. Check the Lumos **Activity Log** filtered on the Adobe app and the **Account Status Updated** event (optionally filter the Target User column). If no event appears, the removal happened outside Lumos, in your IdP or directly in Adobe Admin.

**Create Account fails for federated directories**: Set `AdobeAccountIdType` to `"Federated ID"` and supply the 2-letter `Country` code. The default (blank) creates Enterprise ID accounts.

**A provisioning task failed.** Adobe's User Management API returns HTTP 200 even when an action fails, so Lumos surfaces the real, per-user error as a failed task.

**Common ones:**

* *"Domain for email is not claimed"* — verify the user's email domain in **Adobe Admin Console → Settings → Domains** until it shows Active.
* *"Illegal to invite user from another organization's owned auth src"* — the domain is claimed by a different Adobe org (common after mergers); set up directory trust between the two orgs in Adobe.
* *"The user type requested for the invite does not match the claimed domain type"* — a federated domain with Create Account left on the default Enterprise ID; set `AdobeAccountIdType` to `"Federated ID"` (see the Create Account note above).
* *"String too long ... field: country, max length 2"* — enter a 2-letter ISO country code (`"US"`, not `"United States"`). *"unknown error"* or an internal add error — a transient Adobe-side failure; retry the task first.

**Does suspending a user free up their license?** No. Deactivate (Suspend) removes the user from all product profiles and user groups so they lose access, but the user stays in your Adobe org and the seat stays allocated. Only **Delete** removes the user from the org and returns the license to your pool. Use Suspend to cut access while keeping the account; use Delete to reclaim the seat.

**Deactivate fails for some users but Delete works.** Adobe's deactivate call returns `error.group.remove_failed` when the user has no product/group memberships to remove, or when those memberships are managed by a federated directory rather than by Adobe directly. If your goal is license reclamation, configure the offboarding workflow to use **Delete**, which succeeds in exactly the cases where Deactivate fails.

**Last Login is empty and inactivity workflows don't run.** Adobe's User Management API exposes no last-login or activity data, so the field stays empty and inactivity workflows can't run against Adobe usage directly. If Adobe sits behind your IdP, measure inactivity by the user's last SSO login to Adobe instead — but a long-lived Adobe session lets someone work daily without a fresh SSO login, so tune the session timeout accordingly. Otherwise, run periodic Access Reviews of Adobe entitlements, which most customers use in place of the activity signals Adobe doesn't provide.

**A license removed in Adobe Admin Console keeps coming back.** The assignment source is upstream. If the license flows from an IdP group (for example an Okta group rule), removing it in Adobe does nothing to the group membership and the next sync re-provisions it. Remove access where it is granted — use **Unassign from App** in Lumos, which removes the underlying IdP group memberships — and if it still returns, an IdP group rule is re-adding it.

**"No accounts found in the required application" even though the user has an Adobe account.** The Adobe account is likely matched to a stale identity (for example a deactivated record from an earlier employment stint that shares the email). Find the Adobe account, unmatch it from the stale identity, match it to the active one, and retry the failed tasks.