Use these considerations when designing an identity provider integration with the Anaplan SCIM API.

Decide the system of record

Before you implement SCIM provisioning, decide which system owns user attributes and workspace assignments. For example, your identity provider might own user names, email addresses, active status, and workspace entitlements. Alternatively, some attributes might continue to be managed in Anaplan.

Avoid managing the same fields in both systems unless you have a clear reconciliation process. If a synchronized attribute is changed manually in Anaplan, a later SCIM update from the identity provider might overwrite that change.

Use a non-SSO user for API access

Anaplan recommends using an active, non-SSO user account with the User Admin role to call the SCIM API. This helps ensure that the integration can authenticate reliably and has the required permission to manage users.

The SCIM API supports Basic authentication, Anaplan authentication tokens, and API keys. Choose the authentication method that best fits your identity provider and security model.

Plan workspace entitlement management

Workspace access is managed through SCIM entitlements. Anaplan supports workspace assignment using:

  • WORKSPACE
  • WORKSPACE_IDS
  • WORKSPACE_NAMES

Use workspace IDs where possible because they are more stable than workspace names. Workspace names can change, which can make name-based mappings harder to maintain over time.

There is a limit of 50 workspaces per call, so large entitlement updates may need to be split across multiple requests.

Choose the right update pattern

Use POST /Users to create users and assign their initial workspace access.

Use PUT /Users/{id} when your integration sends the full desired user state. Be careful with this method: if workspace entitlements are omitted, the user may be removed from associated workspaces.

Use PATCH /Users/{id} for targeted updates, such as changing a name, setting active status, or adding or removing specific workspace entitlements. In Anaplan’s SCIM implementation, each patch operation must include a path.

Account for supported SCIM features

Anaplan implements SCIM 2.0, but not every optional SCIM feature is supported. Before relying on a capability, check the metadata endpoints:

  • GET /ServiceProviderConfig
  • GET /ResourceTypes
  • GET /Schemas

These endpoints help confirm supported capabilities, resource types, schemas, attributes, and authentication schemes.

Design filters around supported fields

When searching for users, design queries around supported filter fields and operators. Supported filter fields include id, externalId, userName, name.familyName, name.givenName, and active.

Avoid relying on unsupported filter behavior such as complex attribute filtering, entitlement filtering, unsupported operators, or POST-based search.

Handle partial success

Entitlement updates are not atomic. Anaplan stores entitlement data separately from user data, so an update can partially succeed if the user attributes are saved but entitlement changes fail.

Your integration should inspect response bodies, retrieve the user after updates when needed, and retry only the failed part of the operation.

Test before enabling production provisioning

Test the integration in a controlled setup before enabling production provisioning. Any test users created through SCIM are created at the tenant level and may be visible in the production Anaplan environment. Disable test users when testing is complete.

A recommended approach is to test with a dedicated workspace, test model, and non-production integration account before switching to a production integration account.