Audit

Enterprise

The Audit view provides comprehensive monitoring and tracking capabilities for all user activities within the DataStream platform. It enables administrators to monitor user actions, track system changes, and maintain detailed logs for compliance, security analysis, and operational oversight.

Overview

To access the Audit view

• Go to the Home > Organization pane
• Click Audit

-or-

• Click the hamburger menu on the top left
• Select Organization > Audit

The view displays a chronological record of all system activities with the following essential components:

• Audit table: Comprehensive log display with User, User IP, User ID, Object type, Object, Action, Action Description, and Date columns
• Filter: Advanced filtering options to narrow down audit records by various criteria
• Search bar: Search field with the placeholder Search users or actions
• Pagination controls: Navigate through historical audit records with configurable items per page
• Export: Download the filtered trail as CSV or JSON. See Exporting the Audit Log
• Reset button: Reload the audit log display with the latest activities

Audit Log Columns

The audit table provides detailed information for each recorded activity:

User Information

• User: Email address of the user who performed the action. A row the platform wrote itself, not a user, shows System here and has no user to open. Today that is a director-reported update, a director's lifecycle record and a rule action's notification.
• User IP: Source IP address from which the action was initiated
• User ID: Internal identifier assigned to the user account

Action Details

• Object type: Category of the system component affected (User, Pipeline, Device, Director, AdvancedRoute, AlertRule)

• Object: Specific target of the action (user email, content name, pipeline identifier)

• Action: Type of operation performed (UserCreated, UserDeleted, UserUpdated, LoginSuccess, LoginFailed, TemplateInstalled, PipelineCreated, PermissionDenied, SensitiveDataPolicyUpdated).

  This is a clickable link, the pop-up displays further details of the tracked activity.

  Actions on an object are named <Object><PastTense> — UserCreated, DirectorDeleted, RoleUpdated. Names that used to follow the older verb-first form, such as CreateUser, DeletedDirector or InstalledContentHub, now appear under their new spelling on every row, including rows recorded before the change. Event names that never described an object, such as LoginSuccess, LoginFailed and PermissionDenied, are unchanged. The Action filter still accepts an old name, so a bookmarked filter or a /api/v1/audit?action=DeleteDevice client keeps returning the same rows as DeviceDeleted. The names returned in the table, the export and the action field of the REST API are always the new ones, so anything that matches on action values downstream — a SIEM rule over exported rows, a script reading /api/v1/audit — has to use the new spellings. A Content Hub install used to be filed under object type ContentHub, the feature it was started from rather than what it created; it is now filed under the type of object it created — Pipeline for an installed pack or an installed child pipeline, AdvancedRoute for an installed route — including rows recorded before the change. An operator who filters Object type = ContentHub to find pack installs will no longer find them there; look under Pipeline (or AdvancedRoute for a route install) instead.

  Data access. Starting a capture is recorded: a live data, console log, replay discovery or BACnet discovery capture, and a profiler capture. The row is filed under the object that was read, so it also appears in that object's activity log. Actions are <Object>LiveDataCaptureStarted (Director, Cluster, Device, Target, AdvancedRoute), <Object>ConsoleLogCaptureStarted (Director, Cluster, Device, Target), DeviceReplayDiscoveryStarted, DeviceBacnetDiscoveryStarted, and DirectorProfilerCaptureStarted / DeviceProfilerCaptureStarted. An agent is filed as a Device.

  Each capture also writes one row when it ends, under the same object: <Object>LiveDataCaptureEnded, <Object>ConsoleLogCaptureEnded, DeviceReplayDiscoveryEnded or DeviceBacnetDiscoveryEnded. Its outcome says how it ended: completed, stopped (from the console), restarted (another capture was started in its place), disconnected (the console closed first) or timed_out (a director it reached never reported back). The pop-up shows the capture id, which pairs the row with its start row, the lines the console received, the duration in milliseconds, how many of the director connections it reached reported back and, for a device, its type. A capture that was refused or reached no director writes neither row.

  The start row's pop-up shows the capture's settings: duration, line count, pipeline stage, severity filter and search text. It also shows the screen the capture was started from (detail, pipeline-editor, replay-runs, bacnet-objects or smart-engine) and, for a device, its type. Rows are written per capture, not per page visit. Searches on the Search page are not recorded as captures.

  Director lifecycle. A director reports why it last stopped and whether it came back. Each report is filed under object type Director, against the director that sent it, with System as its user and the director's name as its Object, so it also appears on that director's Activity Logs tab. There are four actions:

  Action	When it is written
  DirectorLifecycleRequested	The director accepted a reload or restart and is shutting down for it. Rarely seen: the director writes it just before it goes down and usually cannot send it in time.
  DirectorLifecycleCompleted	The director is back after a reload or restart the platform asked for, or after a restart to apply an update.
  DirectorCrashRecovered	The director started after a crash. It knows it crashed because it found the lock file its previous process left behind.
  DirectorStartedUnexpectedly	The director started without a request and with no evidence of a crash, for example after a host reboot, a service manager restart, an OOM kill or a recreated container.

  The Action Description says what happened, for example Director restart completed; back after 12s, Director started after a crash or Director started without a request (host reboot, service restart or OOM kill). Director reload refused: <reason> means the director refused the reload and was never down.

  The pop-up shows the record's metadata:

  • reason — reload_requested, restart_requested, update_applied, crash_recovered or unknown
  • state — requested or completed
  • requestId — the platform's reload or restart request, for one the platform asked for
  • detail, generation and timestamp
  • downtimeSeconds — the time from the request to the director being back. It is counted from when the request was made, not from when the service actually stopped.

  A reload or restart started from the console also writes a DirectorReloaded or DirectorRestarted row under the user who started it. That row and the director's DirectorLifecycleCompleted row carry the same requestId, which pairs the request with the director's return. A DirectorReloaded or DirectorRestarted row with no DirectorLifecycleCompleted row for its requestId is a director that never came back. Do not rely on DirectorLifecycleRequested for this: it rarely arrives, so its absence proves nothing.

  The rows worth investigating are DirectorStartedUnexpectedly and DirectorCrashRecovered: a restart someone asked for already has its reason. Agents do not report lifecycle records.

  PowerShell and Cloud Shell. Sign-ins from the PowerShell module and Cloud Shell are filed under object type CliSession, with four actions:

  • CliSignInApproved — a user approved a device code sign-in or authorized a browser sign-in
  • CliSignInDenied — a user denied a device code sign-in
  • CliSessionCreated — a session was created: by a device code, an authorization code, a tenant switch, or opening Cloud Shell
  • CliSessionRevoked — a session was ended early, with the reason

  A token refresh writes no row. Every command run in Cloud Shell writes a CliCommandExecuted row, grouped with the rest of its session, with the command line and its outcome: completed, failed, refused, invalid or cancelled. Secret values in the command line are masked as ***, and the pop-up shows the command. A change made from PowerShell or Cloud Shell is recorded as the same change made in the web interface would be, under the user's email, with the client (powershell or cloudshell) in its details.

  Rule action notifications. The outcome of every notification a rule action was due to send is filed under object type AlertRule, against the rule, once its outcome is final, with System as its user and one of three actions:

  • RuleActionNotificationDelivered — every recipient was reached
  • RuleActionNotificationFailed — at least one recipient was not reached; a partial delivery counts as failed, and the description says how many were missed
  • RuleActionNotificationNotSent — no recipient was tried, because a quota stopped it, or the action was detached, deleted or disabled before its notification went out

  The pop-up shows the reason, error code, attempts, recipients and provider reference. The same rows appear on the rule's Activity Logs tab.

• Action Description: Human-readable explanation of what occurred

• Date: Precise timestamp of when the action took place

Search Functionality

Use the search feature to quickly locate specific audit records. The search functionality provides:

• Real-time filtering: Search results update as you type
• Multi-field search: Searches across usernames, actions, and descriptions
• Clear search: Use the X button to quickly clear the search criteria
• Case-insensitive matching: Finds results regardless of letter case

Searching for specific user accounts filters the audit log to show only activities related to that user, making it easy to track individual user behaviors and actions.

Search matches the action name as it was recorded, so a search for an old spelling such as DeleteDevice is not a reliable way to find every deletion. To find every row of one action, whichever name it was recorded under, use the Action filter instead — it matches both spellings.

Advanced Filtering

Apply sophisticated filters to analyze specific aspects of system activity with multiple filter criteria:

Exporting the Audit Log

The Export menu offers Download as CSV and Download as JSON. The export covers every row matching the current filters, not just the page on screen, and is built server-side and streamed — so a large range shows a Preparing CSV… state first, and a result that hits the cap comes back with a truncation notice.

Export needs the AUDIT_EXPORT permission, which is not the one that grants access to the view. AUDIT_READ lets an account page through the trail; taking a bulk copy of it is a separate, narrower grant carried only by the AUDIT_MANAGER permission set, and by none of the four built-in roles. An account that can read the audit log therefore cannot necessarily export it.

Applied Filters Display

The active filters are shown as removable tags:

• User: Filter by specific user account — selected in the filter form via the Select user field. Optional; leaving it unset returns every account
• From/To dates: The audit period. Both are always set — the form opens with a rolling seven-day range — so the filter is never date-less. The To picker stays disabled until a From date is chosen
• Object type: Filter by object category
• Object: Filter by specific object target
• Action: Filter by action type. The dropdown lists each action once, under its current name; an old name typed into the filter or carried in a bookmarked URL is still accepted and returns the same rows

Filter Management

• Modify button: Edit existing filter criteria
• Clear all button: Remove all applied filters to return to full audit view
• Filter persistence: Applied filters remain active until manually removed

Filter Results

When filters are applied, you can see focused results such as:

• User login sessions from different IP addresses
• Failed login attempts for security monitoring
• Successful authentication events with timestamps

The filtered view displays the narrowed results from the full audit log.