Skip to main content

​
About Adobe

The Adobe integration connects Serval to the Adobe User Management API, the same API that powers user and license administration behind the Adobe Admin Console. Adobe licenses its creative, document, and marketing software (Creative Cloud, Document Cloud, and Experience Cloud) to users through that console. Once connected, Serval can assign and remove Adobe product profiles (licenses) for your users through an installable “Access Management” workflow bundle, and custom workflows can call any part of the User Management API. Workflow requests go to a single Adobe API host for this integration, usermanagement.adobe.io. This integration is currently in Beta. Authentication: OAuth Server-to-Server (client credentials) via Adobe IMS - you paste an Organization ID, Client ID, and Client Secret from the Adobe Developer Console, and Serval handles token exchange and all API authentication headers automatically. No user login or browser-based OAuth flow is involved - the credential acts on behalf of your organization. Data sync: On demand only. Serval does not import or sync Adobe users, licenses, or other resources in the background - Adobe is contacted only when a workflow runs (or when the connection health check runs).
The integration surface is focused on the Adobe User Management API (usermanagement.adobe.io). Other Adobe APIs (Creative Cloud Libraries, Photoshop API, and similar) are not exposed.

​
What the Adobe integration enables

CapabilityDescription
Provision User to AdobeInstallable workflow (part of the “Access Management” bundle) designed as an app entitlement’s custom provisioning workflow. Creates the user in Adobe if needed (as a Federated ID) and assigns the Adobe product profile whose name matches the requested Serval role - no mapping configuration required.
Deprovision User from AdobeInstallable workflow in the same bundle, designed as an app entitlement’s custom deprovisioning workflow. Removes the Adobe product profile whose name matches the revoked entitlement. Works for both access-request-backed removals and access-review remediations. Removes the license only, not Adobe organization membership.
Adobe API requestA general-purpose action that lets any custom workflow call the Adobe User Management API directly. Serval injects authentication (including Adobe’s required API key header) automatically, so workflows never handle credentials.
Anything defined in the Adobe User Management API can be accessed through Serval, including:
  • Listing and looking up users in your Adobe organization
  • Creating users and assigning or removing product profiles (licenses)
  • Managing user groups and group membership
  • Removing users from the organization
Common use cases include self-service Creative Cloud license requests with approval, automatic license reclamation during offboarding, license-tier changes (for example, Single App to All Apps), and periodic audits of who holds which product profile.

​
Get your credentials

Serval connects using an OAuth Server-to-Server credential from an Adobe Developer Console project that includes the User Management API. Adobe’s official setup guide is the UMAPI authentication documentation; the credential type itself is covered in the Adobe OAuth Server-to-Server implementation guide.
Only members of your Adobe organization with the System Admin role can create the User Management API integration in the Adobe Developer Console. Have a system admin perform these steps.
1

Sign in to the Adobe Developer Console

Go to the Adobe Developer Console and sign in as an Adobe System Administrator. Make sure the correct organization is selected in the top-right org picker - the credential is only valid for the org that is selected when you create the project.
2

Create or open a project and add an API

Create a new project (or open an existing one) and choose Add API.
3

Add the User Management API with an OAuth Server-to-Server credential

Select the User Management API (listed under Adobe Services), choose the OAuth Server-to-Server credential type, and click Save configured API. Adding the User Management API automatically attaches the scopes the credential needs (openid, AdobeID, user_management_sdk) - you do not configure scopes by hand, and Serval requests exactly these during the token exchange.
4

Copy the Client ID and Client Secret

Open the project’s OAuth Server-to-Server credential overview page. Copy the Client ID (this is also your API key) and use Retrieve client secret to get the Client Secret.
5

Find your Organization ID

Your Organization ID is a 24-character alphanumeric string followed by the @AdobeOrg suffix (33 characters in total, for example 1234567890ABCDEF12345678@AdobeOrg). It is shown alongside the project credentials in the Developer Console (and under Project overview), and also appears in your Adobe Admin Console URL. See Find your Adobe Organization ID if you have trouble locating it.
The credential must include the User Management API. A credential created without it cannot grant the permissions Serval requests, and the connection will fail when Adobe rejects the token exchange or the first API call. The Client ID is only authorized for the APIs attached to its own project.

​
Connect in Serval

1

Open the Adobe connect form

In Serval, go to Apps -> Available -> Adobe (the tile is marked Beta) and click Connect.
2

Enter your Organization ID

In Organization ID, paste your Adobe organization ID. Helper text: “Your Adobe organization ID (ends with @AdobeOrg).”
3

Enter your Client ID

In Client ID (API Key), paste the Client ID from your credential. Helper text: “The Client ID of your Adobe OAuth Server-to-Server credential.”
4

Enter your Client Secret

In Client Secret (a password field), paste the Client Secret. Helper text: “The Client Secret of your Adobe OAuth Server-to-Server credential.”
5

Save the connection

Click Submit. Serval exchanges the credentials for an access token with Adobe IMS and runs a read-only health check that lists the first page of users in your organization. This exercises the full auth path - the token exchange, the API key header, and org access - so a passing check means the integration is ready to use. The connection appears as “Adobe ([organization ID])”.
All three fields are needed for a working connection, but the form does not mark them with asterisks or block a blank submit - a missing or mistyped value surfaces when the health check or a workflow first calls Adobe. If saving fails, the form shows “Failed to install integration” or “Failed to update integration” (with details appended when available).
Adobe access tokens are short-lived; Serval refreshes them automatically using the stored credential. You never need to rotate tokens by hand - only the client secret, if your security policy requires it.
When editing an existing connection, fields you leave blank (or leave showing their obfuscated placeholder) keep their stored values. To rotate just the Client Secret, click the pencil icon next to the masked value (or Replace on the reconnect form), paste the new secret into the “Enter new value” box, and save - you do not need to re-enter the Organization ID or Client ID. If you rotate the secret in the Adobe Developer Console, update it in Serval as well, because the old secret stops working as soon as rotation completes.

​
Verifying the connection

When you save the connection, Serval runs a read-only health check that lists the first page of users in your organization. A passing check proves the whole authentication path at once: the token exchange with Adobe IMS, the API key header, and access to your organization. If it fails, re-verify the three values against the credential page in the Adobe Developer Console and confirm the credential includes the User Management API. You can also confirm the connection works end to end by running a workflow that reads from Adobe - for example, a small custom workflow that uses the Adobe API request action to list the users in your organization.
Successful authentication does not guarantee provisioning will succeed. The most common failure after Adobe accepts your credentials is a product profile name mismatch - the Serval role or entitlement name must exactly match a product profile name in your Adobe Admin Console.

​
Installable workflow bundle

The integration ships with an Access Management bundle you can install from Apps -> Adobe -> Workflows:
  • Provision User to Adobe - assigns the requested Adobe product profile (license) to a user. If the user does not exist in your Adobe organization yet, the workflow first creates a Federated ID for them, then adds the product profile. Install it, then select it as an app entitlement’s custom provisioning workflow.
  • Deprovision User from Adobe - removes the revoked product profile from a user. Select it as the entitlement’s custom deprovisioning workflow. The user stays in the organization; only the license is reclaimed. Works for both access-request-backed removals and access-review remediations.
These workflows are deliberately plug-and-play with no role-mapping table to maintain. The Adobe product profile comes straight from the Serval role’s name (provisioning) and the revoked entitlement’s name (deprovisioning), sent to Adobe verbatim. Name your Serval roles and entitlements to exactly match the product profile strings in your Adobe Admin Console (for example, “Default All Apps configuration”).
Two scoping assumptions to check before installing:
  • Identity type: user creation assumes your organization uses Federated IDs (SSO-backed). If you use Enterprise IDs or Business IDs, or rely on SSO just-in-time provisioning, adjust the user-creation step after installing.
  • SSO access is separate: these workflows manage only the Adobe license. If sign-in to Adobe is gated by an IdP or directory group, grant or revoke that group in your IdP (or as its own Serval step) - assigning a product profile does not by itself let the user log in.

​
Using Adobe in workflows

Once connected, use the Adobe API request action to call any User Management API endpoint. The action is schema-less - pass the path, method, and body directly, and resolve request and response shapes from the UMAPI documentation. Serval injects authentication automatically on every call, so workflows never handle credentials:
  • The Bearer token from the OAuth Server-to-Server exchange.
  • The X-Api-Key header (your Client ID), which Adobe requires on every request. Serval always sets this and a workflow cannot override it.
Your organization ID is available from the integration context, so workflows never hardcode it: 
import { workflow } from "serval/core";
import * as adobe from "serval/integrations/adobe";

export const main = workflow({
  fn: async (_args: {}, ctx: adobe.context.AdobeIntegration) => {
    const { orgId } = ctx.integrations.adobe;

    // List the first page of users in the organization.
    return await adobe.apiRequest(
      {
        path: `/v2/usermanagement/users/${encodeURIComponent(orgId)}/0`,
        method: "GET",
      },
      ctx,
    );
  },
});

​
Common endpoints

PathMethodNotes
/v2/usermanagement/users/{orgId}/{page}GETList users, paginated by page number. The response’s lastPage flag tells you when to stop.
/v2/usermanagement/organizations/{orgId}/users/{userString}GETLook up a single user by email.
/v2/usermanagement/groups/{orgId}/{page}GETList user groups and product profiles.
/v2/usermanagement/action/{orgId}POSTThe batch action API - create users, add or remove product profiles and user groups, and remove users from the org. Each entry’s do array runs steps in order.
The action API returns a summary (result, completed, notCompleted, errors) rather than failing the HTTP request, so always check notCompleted and errors in your workflow. The pre-built provisioning workflows above already do this and fail loudly on partial completion.
Adobe throttles the User Management API per organization. If you build bulk workflows (for example, a license audit across thousands of users), expect occasional 429 responses and retry with backoff per the Retry-After header. See Adobe’s UMAPI documentation for current limits and the action commands reference for batch request shapes.

​
Gotchas and troubleshooting

The installed workflows are deliberately plug-and-play with no mapping layer: the requested role’s name (provisioning) and the revoked entitlement’s name (deprovisioning) are sent to Adobe verbatim as the product profile to assign or remove. Name your Serval roles and entitlements to match the exact product profile strings in your Adobe Admin Console (for example, “Default All Apps configuration”), including case and spacing, or the workflow fails with an Adobe error. When using the Adobe API request action directly, check the errors array in the action API response - Adobe returns a per-entry errorCode and message identifying the failing step.
The Provision User to Adobe workflow creates users as Federated IDs (skipping creation if the user already exists), which assumes your organization uses Federated IDs (SSO). Organizations using Enterprise or Business IDs, or SSO just-in-time provisioning, should adjust or remove that step after installing. The country defaults to “US” and first/last names are derived from the email address - enrich the workflow from your HR system or identity provider if accurate names matter.
Both workflows manage only the Adobe license (product profile). Sign-in access through your identity provider or a directory group is a separate access grant managed in your IdP or as its own Serval step - assigning a product profile does not by itself let the user log in. Deprovisioning removes one product profile; it does not remove the user from your Adobe organization.
Serval requests Adobe’s user management permissions (the openid, AdobeID, and user_management_sdk scopes) when exchanging tokens. A credential created without the User Management API cannot grant them, so the token exchange or the first API call fails even though the Client ID and Secret look valid. Add the User Management API to the project in the Adobe Developer Console, and confirm it is attached to the same project as the credential.
Confirm the Organization ID ends with @AdobeOrg and matches the org that was selected in the Developer Console when you created the project. Confirm the credential is OAuth Server-to-Server - not JWT (Adobe’s deprecated Service Account credential type) and not an OAuth Web App credential. Confirm the User Management API is added to the same project as the credential.
The client secret may have been rotated in the Adobe Developer Console. Update the secret in Serval via Apps -> Adobe -> Configure; the old secret stops working as soon as rotation completes.
Per Adobe’s documentation, only members of the organization with the System Admin role can create the User Management API integration in the Adobe Developer Console. If you cannot add the API or see the credential, ask a system admin to create the project for you.
The edit form shows the saved Client Secret obfuscated (bullet characters plus its last 4 characters). Submitting with untouched or blank fields keeps the stored Organization ID, Client ID, and Client Secret, so you can safely update a single field without re-entering the others.
The Adobe tile is flagged Beta, and Serval does not ship a generated catalog of Adobe endpoints. Custom workflows using the Adobe API request action should consult Adobe’s online references for request and response shapes - the UMAPI documentation and the action commands reference. Authentication, including Adobe’s required API key header, is always added by Serval automatically and cannot be overridden by a workflow.

​
External Resources

Need help? Contact support@serval.com for assistance with your Adobe integration.