Overview

The SIEM integration forwards platform audit events to your Security Information and Event Management (SIEM) system. Once connected through Integration Manager, all audit events for your account are delivered automatically — including user administration, account configuration changes, and Integration Manager activity.

Events are forwarded without filtering. Filtering, alerting, routing, retention policies, and dashboards are managed within your SIEM platform. Each event shares a consistent top-level structure, with an extra_data object containing event-specific details. Because the extra_data schema varies by event type, parsers should handle nullable and optional fields gracefully.

Before you begin

The SIEM integration must be enabled for your account. Contact your Customer Success Manager (CSM) or Professional Services representative to request access and confirm which destination you want to use.

You will also need permission to manage connections in Integration Manager and the credentials or connection details required by your SIEM platform.

Connect your SIEM platform

After the integration has been enabled:

1. Open Integration Manager.
2. Go to Connections.
3. Select the connection tile for your SIEM platform.
4. Complete any connection settings shown on the tile.

After the connection is configured successfully, audit events begin flowing to your SIEM platform.

Validate the connection

After configuring the connection, perform a low-risk auditable action, such as creating a test object in an approved test environment. Then confirm that:

1. The event appears in your SIEM platform.
2. The event id and timestamp are searchable.
3. Your parser retains the complete event, including extra_data.
4. Nullable fields do not cause parsing or ingestion failures.

Event delivery

The integration forwards all available audit events for your account. Events are not filtered by event type, severity, user, or source before delivery.

Configure filtering, alerting, routing, retention, and dashboards in your SIEM platform. Because all available events are forwarded, consider expected event volume when configuring ingestion and retention.

Audit events

Examples of auditable activity include:

The events available to your account can vary by product features and configuration. Treat this list as illustrative rather than exhaustive.

Event structure

Each event has a unique identifier and timestamp, together with information about the account, actor, action, and affected object when available.

Fields may be null, empty, or absent when a value is not applicable or is unavailable. SIEM parsing and detection rules should handle nullable and optional fields without rejecting the event. Do not rely on optional fields as the sole basis for correlation or alerting.

Example: Integration Manager event

The following sanitized example records the creation of an Integration Manager object. Identifiers and values are illustrative.

{
  "payload": {
    "id": "123e4567-e89b-12d3-a456-426614174000",
    "timestamp": "2026-09-09T10:27:30.794078+00:00",
    "tenant_id": "123456",
    "user_id": null,
    "source": null,
    "event_type": "INTEGRATION",
    "severity": null,
    "attributes": null,
    "data": null,
    "extra_data": {
      "actor": {
        "displayName": "user@example.com",
        "id": null,
        "type": "user"
      },
      "note": "",
      "ipAddress": "",
      "objectName": "example-siem-connection",
      "action": "CREATE",
      "campaign": null,
      "details": null,
      "actionDate": 1788949650794,
      "objectId": null,
      "account": "EXAMPLE-ACCOUNT"
    }
  },
  "params": {}
}

For this event:

• event_type identifies the event as Integration Manager activity.
• extra_data.actor describes the actor when that information is available.
• extra_data.action identifies the action performed, in this case CREATE.
• extra_data.objectName identifies the affected object when available.
• extra_data.actionDate is the action time expressed as Unix epoch time in milliseconds.

The fields within extra_data are event-specific. Build parsers that tolerate additional fields and do not assume every event type has the same nested structure.

Example: User locked

The following sanitized example records a support user locking a user account.

{
  "payload": {
    "id": "123e4567-e89b-12d3-a456-426614174001",
    "timestamp": "2026-09-09T10:38:28.914146+00:00",
    "tenant_id": "123456",
    "user_id": null,
    "source": null,
    "event_type": "USER",
    "severity": null,
    "attributes": null,
    "data": null,
    "extra_data": {
      "actor": {
        "displayName": "Example Support User",
        "organisation": "Example Organization",
        "id": "195263",
        "type": "supportUser"
      },
      "note": "Reason: user locked for testing",
      "ipAddress": "192.0.2.25",
      "objectName": "Example User (test.user@example.com)",
      "action": "LOCK",
      "campaign": null,
      "details": null,
      "actionDate": 1788950308914,
      "objectId": 218352,
      "account": "EXAMPLE-ACCOUNT"
    }
  },
  "params": {}
}

For this event, event_type is USER and extra_data.action is LOCK. The actor identifies the support user who performed the action, while objectName and objectId identify the affected user when available. The note can contain the reason supplied for the action.

Example: Support user acting on behalf of another user

Some events are generated while a support user is acting on behalf of another user (sometimes described as mimicking that user). These events include both actor and onBehalfOf details so that the initiating support user and represented user can be distinguished.

{
  "payload": {
    "id": "123e4567-e89b-12d3-a456-426614174002",
    "timestamp": "2026-09-09T10:34:24.749474+00:00",
    "tenant_id": "123456",
    "user_id": null,
    "source": null,
    "event_type": "INTEGRATION",
    "severity": null,
    "attributes": null,
    "data": null,
    "extra_data": {
      "actor": {
        "displayName": "support.user@example.com",
        "organisation": "Example Organization",
        "id": "195263",
        "type": "supportUser"
      },
      "note": "",
      "onBehalfOf": {
        "displayName": "represented.user@example.com",
        "id": "210032",
        "type": "user"
      },
      "ipAddress": "",
      "objectName": "example-integration-object",
      "action": "CREATE",
      "campaign": null,
      "details": null,
      "actionDate": 1788950064749,
      "objectId": null,
      "account": "EXAMPLE-ACCOUNT"
    }
  },
  "params": {}
}

When extra_data.onBehalfOf is present:

• actor identifies the support user who performed the action.
• onBehalfOf identifies the user whose context the support user was acting in.
• The event should not be attributed solely to onBehalfOf.displayName.

For investigations and detection rules, retain both identities and the actor.type value. This makes it possible to distinguish direct user actions from actions performed by a support user on the user's behalf.

Troubleshooting

If events do not appear in your SIEM platform:

• Confirm that the connection in Integration Manager > Connections is authenticated and active.
• Verify that the destination credentials have permission to ingest events.
• Check the SIEM platform's ingestion, indexing, and parsing logs.
• Confirm that destination-side filters or routing rules are not discarding events.
• Perform a new auditable action and search by its approximate timestamp.

If the connection is active but events are still unavailable, contact your CSM or Professional Services representative. Include the affected account, SIEM destination, approximate event time, and event type. Do not include passwords, API keys, access tokens, or other credentials in a support request.

Security guidance

• Protect SIEM credentials according to your organization's security policies.
• Grant the connection only the permissions required to ingest events.
• Never place access tokens or authorization headers in documentation, tickets, chat messages, or detection rules.
• Apply destination-side access controls and retention policies appropriate for audit data, which can contain user identifiers and other account information.