IAM logs

Audit identity and access management events such as logins and provisioning.

IAM Logs

The IAM Logs screen is your real-time audit trail for all identity and access management events flowing through DPMS — specifically every operation your identity provider sends over the SCIM provisioning protocol. IT administrators, DPOs, and compliance officers come here to answer questions like "Did today's user sync work?" or "Why hasn't the new hire's account appeared yet?" Unlike the other IAM screens, this one is purely observational: you cannot create, edit, or delete anything here. You come here to watch, diagnose, and document.

How to open it

Navigate to IT Settings in the left-hand menu, expand the IAM Settings section, and click Logs. You need the IT Settings IAM permission to access this screen. If you do not have that permission, DPMS will show a "403 Forbidden" page instead. There is no partial-access state — either you can see the full log table or you cannot see this screen at all.

What you see

At the very top of the content area you will find a breadcrumb trail reading IT Settings › IAM Settings › Logs, with "IAM Settings" shown as a clickable blue link and "Logs" in bold blue as your current location. Flanking the "Logs" label are two small arrow buttons (left chevron and right chevron) that let you jump directly to the previous or next sub-section within IAM Settings without going back to the parent menu.

Below the breadcrumb is a section heading — also labelled Logs — followed by a full-width dividing line that separates the title from the data table.

The main body of the screen is a paginated, read-only data table. A single tab labelled All sits above the table — it is pre-selected and cannot be deselected. The table loads automatically when you arrive, and more rows are appended as you scroll toward the bottom (infinite scroll). There are no checkboxes, no action buttons, no "Create" option, and no filters or search bar. This is by design: log entries are immutable audit records.

Working with this screen

Investigating a failed user provisioning sync

This is the most common reason an IT administrator visits this screen. Suppose a new employee was added in your identity provider (for example, Microsoft Entra ID or Okta) but their account has not appeared in DPMS.

Navigate to IT Settings › IAM Settings › Logs.
The table loads with the most recent entries at the top. Look at the Date column — it shows timestamps down to the millisecond, so you can pinpoint exactly when your identity provider attempted the sync.
Scan the Http column (the HTTP status code column). A successful provisioning call shows 200 or 201. If you see 401, the SCIM token configured in your identity provider is wrong or expired — go to the Tokens screen and verify your token. If you see 404, the target resource was not found in DPMS. A 500 code indicates a server-side error within DPMS itself.
Click across to the Log column for any suspicious row. This column contains the full detail of what happened — error messages, the affected user or group name, or the raw response. Because SCIM messages can be long, the cell wraps text freely and the row will expand to accommodate it.
Once you have identified the cause, navigate to the appropriate IAM configuration screen (for example, Tokens to regenerate a SCIM token, or SCIM Overview to verify SCIM is enabled) and make the necessary fix.

Verifying that a newly enabled SCIM integration is working

After you have enabled SCIM on the SCIM Overview screen and generated a SCIM token on the Tokens screen, you want confirmation that the first provisioning events are landing correctly.

Go to IT Settings › IAM Settings › Logs.
Look at the most recent entries at the top of the table. The Protocol column should confirm SCIM for each row.
Check the Event column to confirm the expected operation type (for example, a user create or group update event matching what you triggered in your identity provider).
Verify the Http column shows 200 or 201 for each row. If all rows show 401, your identity provider is sending requests with the wrong SCIM token — return to the Tokens screen to copy the correct token value and paste it into your identity provider's configuration.
Use the Type column to confirm the category of event matches your expectations (for example, whether it is a user event or a group event).

Preparing audit evidence for a compliance review

During a SOC 2, ISO 27001, or GDPR audit, an external auditor may ask you to demonstrate that all user provisioning events are being logged with sufficient detail.

Navigate to IT Settings › IAM Settings › Logs.
Scroll through the table to show the auditor that every SCIM operation — creates, updates, and deletes — is captured with a precise timestamp (the Date column shows millisecond precision), the protocol used, the event type, and the HTTP outcome.
Because the Date column uses millisecond-level timestamps, the auditor can cross-reference specific events against your identity provider's own audit log to verify completeness.
Point out the Log column, which contains the full detail of each event, demonstrating that the log is substantive, not just a header record.
If you need to show entries from a specific time window, scroll to that point in the table. Note that there is no date filter on this screen, so you will need to scroll manually.

Performing a routine monthly access control review

A compliance officer performing periodic monitoring can visit this screen to look for anomalies — unusual volumes of failed events, unexpected bulk deletions, or clusters of server errors.

Navigate to IT Settings › IAM Settings › Logs.
Scroll through recent entries, paying attention to the Http column for any spike in 4xx or 5xx codes.
Watch the Event column for unexpected operation types — for example, a large number of group-deletion events when none were planned.
Because the screen is read-only, you can browse freely without any risk of accidentally changing any configuration.

Field reference

Date — The exact date and time the log entry was recorded, shown to millisecond precision (for example, 01/15/2025, 14:32:07.842). If a log entry has no valid timestamp, a dash is shown instead. Use this column to correlate events with your identity provider's own audit logs.

Type — The category classification of the log entry. This indicates the broad type of IAM event (for example, whether it relates to user provisioning or group management).

Protocol — The provisioning protocol used. In practice this will almost always be SCIM, indicating the event arrived via the SCIM 2.0 standard. This field exists to distinguish SCIM events from any other protocol-level events that may be logged in the future.

Event — The specific SCIM operation that was performed. Typical values include operations such as creating a user, updating a user's attributes, deleting a user, creating a group, updating a group, or modifying group membership — following SCIM protocol terminology.

Http — The HTTP status code returned by the DPMS SCIM endpoint in response to the provisioning request. This is often the first column to check when troubleshooting. Codes in the 200–299 range indicate success. 401 means the SCIM token is invalid or missing. 404 means the target resource was not found. 5xx codes indicate a server-side error within DPMS. There is no special formatting for error codes; you read the raw number.

Log — The full log message or payload detail for the event. This can include error messages, the name of the affected user or group, operation outcomes, or verbose SCIM error descriptions. This column takes up all remaining width in the table, and its cell wraps text freely, so long messages will expand the row height. This is the richest source of diagnostic information on the screen.

How this connects to the rest of DPMS

The IAM Logs screen sits at the end of the IAM configuration chain. You configure SCIM and tokens elsewhere; here you observe the results.

The data in this table depends entirely on what you have set up on the other IAM screens:

SCIM Overview — SCIM must be enabled before any provisioning events flow through. If SCIM is turned off, the log table will be empty or will show only failed authentication attempts.
Tokens — The SCIM token you generate on the Tokens screen is what your identity provider uses to authenticate. A missing or expired token produces a wall of 401 entries here.
SAML/OAuth and Active Directory — If your organisation has enabled Entra ID provisioning via the Active Directory screen, SCIM provisioning cannot run simultaneously. If you activate Entra ID and then check this Logs screen, you will find no new SCIM events — that is expected behaviour.
Roles Mapping — Group provisioning events visible in the Log column (with group names) let you verify that groups defined in your Roles Mapping configuration are being received correctly from your identity provider.

After reviewing this screen during a troubleshooting session, your next step is typically to return to one of the configuration screens — Tokens, SCIM Overview, or SAML/OAuth — to fix whatever the logs revealed.

You can navigate directly to any adjacent IAM sub-section by clicking the left or right chevron buttons in the breadcrumb, or by clicking the blue IAM Settings breadcrumb link to return to the IAM parent section.

Tips & common pitfalls

Heads up: An empty table does not automatically mean nothing is happening. The two most common causes are (1) SCIM has never been enabled on the SCIM Overview screen, and (2) the SCIM token used by your identity provider has expired. An expired token still generates log entries — but every single row will show 401 in the Http column. Check SCIM Overview first before concluding the pipeline is silent.

Heads up: There is no search bar and no column filters on this screen. You cannot filter to "only errors" or "only group events." If you need to find a specific event in a high-volume log, you must scroll and scan visually. For large-scale log analysis, consider working directly with the underlying database or an export mechanism.

Millisecond timestamps are intentional. The Date column on this screen is more precise than on other DPMS list screens. When cross-referencing events with your identity provider's audit log, use the millisecond value for exact matching.
The Log column rows can get tall. SCIM error payloads can be verbose. If the table becomes difficult to scan, widening your browser window helps because the Log column fills the remaining available space.
Entra ID and SCIM are mutually exclusive. If your organisation has enabled Entra ID provisioning via the Active Directory screen, no new SCIM events will appear here — that is by design, not a bug. Check the Active Directory screen to confirm which integration is active.
Checkboxes are deliberately absent. Unlike most other DPMS list screens, you cannot select rows for bulk export or any other bulk action. Log entries are immutable audit records and cannot be modified from the UI.