SCIM Audit Events

Descope can generate an audit event for every SCIM call your IdP makes against a tenant (create, update, patch, or delete for users and groups).

Each event fires off a SCIMEvent Action that stores structured data so you can see what was sent in the request, what changed, and whether the call succeeded.

These events are different from the generic user-related audit events created from SCIM, such as UserCreated or UserModified.

Those may still appear when Descope updates users or groups, regardless of if SCIM audit events are enabled or not.

Overview

When SCIM audit logging is enabled for your organization, Descope writes one audit row per qualifying SCIM operation. The Action itself will be titled SCIMEvent and Type is Information, including for failures. If there was a failure than the error field will be set under Data.

SCIM-specific keys on the row are documented in the Data fields reference table below.

Standard audit Data fields (such as request_details, correlation_id, and network or device context when available) are populated the same way as described in Audit Events.

Note

If SCIM is not enabled for the tenant on a given request, Descope may skip writing a SCIM audit entry for that call. If you expect events but see none, confirm SCIM configuration and that your license includes SCIM.

Where to Find SCIM Audits

You can inspect SCIM audits in the following places:

Descope Console — Open Audits and filter or search for action SCIMEvent.
Management API / SDKs — Call Search Audit with actions containing SCIMEvent, optionally combined with tenant or text search.

Data Fields Reference

Key	Description
`scim_action`	The SCIM operation; see SCIM actions.
`scim_request`	What the IdP sent: object built from the inbound SCIM body (non-meaningful internal fields may be omitted).
`scim_result`	On success, SCIM-shaped object for the resource after the call (or a small identifier map for deletes). Omitted when the operation fails.
`Change`	When present, a normalized field-level diff (same shape as on `UserModified`), including for some creates and for group or membership updates.
`error`	Present on failure; human-readable error message.

SCIM Actions

The scim_action value is always one of the following:

`scim_action`	Operation
`scim_create_user`	Create user
`scim_update_user`	Replace user (PUT)
`scim_patch_user`	Patch user
`scim_delete_user`	Delete user
`scim_create_group`	Create group
`scim_update_group`	Replace group (PUT)
`scim_patch_group`	Patch group
`scim_delete_group`	Delete group

For user operations, User ID and Login IDs on the audit row are set when Descope resolves the affected user. For group-only operations, those user-oriented columns may be empty; use scim_request / scim_result and Change for group and membership details.

Group Membership in `Change`

For group create, update, and patch, membership updates may appear under Change using these keys:

Key	Description
`added_members`	Member identifiers added. The list is included only when its size is within Descope’s limit (see below).
`added_members_count`	Always set to the number of added members.
`removed_members`	Member identifiers removed (same list/count rules as `added_members`).
`removed_members_count`	Always set to the number of removed members.
`replaced_members`	Member identifiers after a replace operation (for example, via PATCH). Same list/count rules as `added_members`.
`replaced_members_count`	Always set to the number of members in the replacement set.

If the number of members in a list exceeds Descope’s maximum (default 40 per list), Descope records the corresponding *_count field but does not include the full member list, so audit payloads stay bounded while still showing how many members were affected.

Examples

Successful User Creation

Expand the audit Data in the console or API response. It will resemble:

{
  "scim_action": "scim_create_user",
  "scim_request": {
    "userName": "alice@example.com",
    "displayName": "Alice Example"
  },
  "scim_result": {
    "id": "u1"
  },
  "correlation_id": "xx",
  "request_details": {}
}

Exact keys depend on your IdP and attribute mapping. Change may also be present on create when Descope records provisioned fields.

Failed Operation

{
  "scim_action": "scim_create_user",
  "scim_request": {
    "userName": "alice@example.com"
  },
  "error": "user already exists"
}

Was this helpful?

Ask AI about this page

On this page