Audit Log

9 minute(s) read

Audit Logs #

Overview #

ReportWORQ provides two distinct audit logging systems that together give administrators full visibility into both system-level activity and job execution history:

System Audit Log — records configuration changes, security events, scheduling actions, and other application-level activity.
Job Audit Log — records the outcome of every job execution, including runtime details and parameter overrides.

Both logs are accessible from the Administration → Audit Logs screen and are governed by configurable retention policies.

Enabling and Configuring Audit Logs #

Audit logging is controlled from Administration → Configuration → Logging.

Setting	Description
Enable Audit Logging	Turns the System Audit Log on or off. When disabled no system-level audit entries are written.
Log Retention (Audit)	The number of days to keep System Audit Log files. Set to `0` to retain files indefinitely. Files older than the retention threshold are automatically purged.
Enable Job History Audit Logging	Turns the Job Audit Log on or off. When disabled no job history JSON files are written.
Log Retention (Job History)	The number of days to keep Job History Audit Log files. Set to `0` to retain files indefinitely.

Retention is enforced at the file creation date. A value of 1 day means that any file created before today is eligible for deletion.

Audit Log Viewer Screen #

Both log types are accessible from a single screen:

Navigate to Administration → Audit Logs.
Use the log selector drop-down in the toolbar to switch between available log files. Files are grouped into two categories:

System Audit — one file per day named yyyy-MM-dd.
Job History — one file per day that contains all job executions logged on that date.

Click Refresh to reload the currently selected log.
Click Documentation… to open the online help for this screen.

System Audit Log #

Purpose #

The System Audit Log captures administrative and operational events across the ReportWORQ application. It is the authoritative record for compliance, troubleshooting, and change management.

UI — Grid Columns #

When a System Audit file is selected the viewer displays a sortable, filterable tree-list with the following columns:

Column	Description
Source	The machine name and application component that generated the entry (e.g., `SERVER01 - Web App`).
Timestamp	Date and time the entry was recorded.
Category	The functional area associated with the entry (see Object Categories below).
User	The identity of the user whose action triggered the entry. System-initiated actions are recorded as `SYSTEM`.
Object Type	A more specific type descriptor within the category (e.g., the type name of the object that was modified).
Object Name	The name of the specific object that was acted upon.
File	The filename, if any, associated with the change.
Modifications	A comma-separated list of property names that were changed, when applicable.
Description	The human-readable message describing the action.

Detail Sidebar #

Clicking the ⓘ (View Details) button on any row opens a sidebar panel with the full audit record:

Audit Entry section — shows the object category/type, the acting user, the description message, and any contextual trace messages recorded during the operation.
Object Information section (when present) — displays the object type, name, and the associated filename.
Modifications section (when present) — lists each changed property with a before and after value side by side, allowing you to see exactly what changed.
Navigation — use the left/right arrow buttons at the top of the sidebar to step through adjacent entries without closing the panel.
Download — click the download icon (memo with info circle) to export the full entry as a text file. The export includes the timestamp, category, environment details, user context, trace messages, full object context, property-level diff, and the serialized previous and new item payloads.

Entry Types #

Every system audit entry has a Type that indicates the nature of the action:

Type	Logged By	Description
`INFORMATION`	`LogMessage()`	General informational event, e.g., application start.
`WARNING`	`LogWarning()`	A non-fatal condition worth noting.
`ERROR`	`LogError()`	An error condition, including the exception details.
`CREATE`	`LogAddition()`	A new object was created.
`UPDATE`	`LogChange()`	An existing object was modified; includes before/after values.
`DELETE`	`LogDeletion()`	An object was deleted; includes the previous value.

Object Categories #

The Category field on every entry comes from the ObjectCategoryEnum and indicates the functional area of the system that generated the event:

Value	Description
`Informational`	Application start/stop events and software update notifications.
`Licensing`	License validation and management events.
`Security`	User management, sign-in activity, and permission changes.
`Settings`	Changes to application settings, datasource connections, providers, and distributors.
`BuiltInReportProvider`	File and folder changes within the built-in report provider (e.g., uploads, renames, deletes).
`Scheduling`	Schedule creation, modification, deletion, and trigger events.
`Jobs`	Job authoring events such as create, update, or delete of job definitions.
`Contacts`	Address book / contacts management.
`GlobalVariables`	Global variable create, update, and delete events.
`JobHistory`	Job history-related activities such as retention purges.
`Writeback`	Contribution writeback activity.
`MessageTemplates`	Message template create, update, and delete events.
`ReportDataModels`	Report data model changes.
`ReportModels`	Report model changes.
`DataModels`	Data model changes.
`ReportSpecs`	Report specification changes.

Environment Context #

Every audit entry captures the environment from which it originated:

Field	Description
`MachineName`	The hostname of the server that generated the entry.
`Application`	The ReportWORQ application component (`Web App`, `Job Runner`, `Staff Console`, `Load Balancer`).
`HostingType`	The deployment model (`OnPrem`, `SingleTenantCloud`, `MultiTenantCloud`).
`ApplicationIdentity`	The OS-level service account identity of the running process.

Job Audit Log #

Purpose #

The Job Audit Log records the full outcome of every job execution. It has two uses:

UI review — administrators can inspect execution history, timing, parameter overrides, and per-runtime-job results directly in the Audit Log viewer.
Systems integration — each execution is written as a standalone, machine-readable JSON file designed to be consumed by external systems such as data warehouses, monitoring tools, or automation pipelines.

UI — Grid Columns #

When a Job History file is selected the viewer displays a sortable, filterable grid with the following columns:

Column	Description
Name	The name of the job that was executed.
Status	The final execution status (e.g., `Success`, `Failure`).
Execution ID	A globally unique identifier for the execution instance.
Start Time	The date and time the execution began.
End Time	The date and time the execution completed.
Elapsed Time	Total execution duration in `hh:mm:ss` format.
Parameter Overrides	A comma-separated list of parameter names and values that were overridden at runtime.
RuntimeJob Count	The number of individual runtime jobs spawned during the execution.
Runtime Job Names	A comma-separated list of the runtime job names.

Each row can be expanded to reveal a nested grid of runtime jobs showing their individual Name, Status, Elapsed Time, and Parameters.

Detail Sidebar #

Clicking the ⓘ (View Details) button on any row opens a sidebar panel with the full job execution record:

Job Audit Entry section — shows the job name and execution ID.
Parameter Override Information section (when present) — lists each parameter name and the value that was used to override the default.
Runtime Jobs section (when present) — lists each runtime job and the parameter values used for that specific report.
Navigation — use the left/right arrow buttons at the top of the sidebar to step through adjacent entries without closing the panel.
Download — click the download icon to export a text-format summary of the execution record.

Job Audit Log Folder (Systems Integration) #

Storage Location #

Job History Audit Log files are stored in the following folder on the ReportWORQ server:

{ReportWORQ Repository Path}/JobHistoryAuditLog/

File Format #

Each job execution produces a single JSON file named after the execution ID:

{ExecutionId}.json

For example: a3f5c812-9b2d-4e71-bf30-1234abcd5678.json

Files are written once when the execution completes and are not modified afterwards, making them safe to consume by file-watching integrations.

JSON Schema #

Each file contains a single JSON object that matches the following schema:

{
  "ExecutionId":        "string   — globally unique identifier for the execution (UUID format)",
  "Name":              "string   — name of the job that was executed",
  "Status":            "string   — final execution status (e.g. 'Success', 'Failure')",
  "StartTime":         "string?  — ISO 8601 datetime when execution started, or null",
  "EndTime":           "string?  — ISO 8601 datetime when execution ended, or null",
  "ElapsedTime":       "string   — total duration in hh:mm:ss.fffffff format",
  "ParameterOverrides": [
    {
      "Name":  "string — parameter name",
      "Value": "string — overridden parameter value"
    }
  ],
  "RuntimeJobCount":   "integer  — number of runtime jobs spawned",
  "RuntimeJobs": [
    {
      "Name":           "string  — name of the runtime job (typically the report name)",
      "Status":         "string  — status of this individual runtime job",
      "OutputFileName": "string  — filename of the generated output file, if any",
      "StartTime":      "string? — ISO 8601 datetime, or null",
      "EndTime":        "string? — ISO 8601 datetime, or null",
      "ElapsedTime":    "string  — duration in hh:mm:ss.fffffff format",
      "Parameters": [
        {
          "Name":   "string   — parameter name",
          "Values": ["string"] "— list of parameter values applied to this runtime job"
        }
      ]
    }
  ],
  "MachineName":        "string  — hostname of the server that ran the job",
  "ApplicationIdentity":"string  — OS-level service account identity of the running process",
  "WorkspaceId":        "string  — identifier of the workspace in which the job resides",
  "WorkspaceName":      "string  — display name of the workspace"
}

Example JSON Entry #

{
  "ExecutionId": "a3f5c812-9b2d-4e71-bf30-1234abcd5678",
  "Name": "Monthly Revenue Report",
  "Status": "Success",
  "StartTime": "2025-06-01T08:00:05.123Z",
  "EndTime": "2025-06-01T08:02:47.456Z",
  "ElapsedTime": "00:02:42.3330000",
  "ParameterOverrides": [
    { "Name": "Region", "Value": "EMEA" }
  ],
  "RuntimeJobCount": 3,
  "RuntimeJobs": [
    {
      "Name": "Revenue_EMEA_Q1",
      "Status": "Success",
      "OutputFileName": "Revenue_EMEA_Q1.xlsx",
      "StartTime": "2025-06-01T08:00:06.000Z",
      "EndTime": "2025-06-01T08:01:10.000Z",
      "ElapsedTime": "00:01:04.0000000",
      "Parameters": [
        { "Name": "Quarter", "Values": ["Q1"] },
        { "Name": "Region",  "Values": ["EMEA"] }
      ]
    },
    {
      "Name": "Revenue_EMEA_Q2",
      "Status": "Success",
      "OutputFileName": "Revenue_EMEA_Q2.xlsx",
      "StartTime": "2025-06-01T08:01:11.000Z",
      "EndTime": "2025-06-01T08:02:00.000Z",
      "ElapsedTime": "00:00:49.0000000",
      "Parameters": [
        { "Name": "Quarter", "Values": ["Q2"] },
        { "Name": "Region",  "Values": ["EMEA"] }
      ]
    },
    {
      "Name": "Revenue_EMEA_Q3",
      "Status": "Success",
      "OutputFileName": "Revenue_EMEA_Q3.xlsx",
      "StartTime": "2025-06-01T08:02:01.000Z",
      "EndTime": "2025-06-01T08:02:47.000Z",
      "ElapsedTime": "00:00:46.0000000",
      "Parameters": [
        { "Name": "Quarter", "Values": ["Q3"] },
        { "Name": "Region",  "Values": ["EMEA"] }
      ]
    }
  ],
  "MachineName": "RWSERVER01",
  "ApplicationIdentity": "DOMAIN\\reportworq-svc",
  "WorkspaceId": "ws-001",
  "WorkspaceName": "Finance"
}

Integration Notes #

Files are written once at execution completion and never modified, making them safe to pick up with file-watching or polling integrations.
Each file is self-contained — all context needed to identify and process the execution is present within the file itself.
The ExecutionId can be used to correlate entries across systems.
The ParameterOverrides array is empty (or omitted) when no runtime overrides were applied.
The Parameters array within each RuntimeJob reflects the final resolved parameter values used for that specific report render.
Files are retained according to the Job History Audit Log Retention setting in Administration → Configuration → Logging. Integrations that process files should do so before the retention window expires, or copy the files to external storage.

Summary #

Feature	System Audit Log	Job Audit Log
Primary use	Change tracking, compliance, security auditing	Job execution history, integration, reporting
Storage location	`{Repo}/AuditLog/` (managed by Serilog)	`{Repo}/JobHistoryAuditLog/{executionId}.json`
File format	Serilog structured log	One JSON file per execution
Enabled via	Enable Audit Logging setting	Enable Job History Audit Logging setting
Retention setting	Audit Log Retention (days)	Job History Audit Log Retention (days)
Detail sidebar	Object, user, trace, before/after diffs, download	Job name, execution ID, parameter overrides, runtime jobs, download

Updated on April 15, 2026

Create A Support Ticket

Getting Started

Training Tutorial and Videos

User Guide

Administration Guide

Technical Articles

Support

General

Audit Log

Audit Logs #

Overview #

Enabling and Configuring Audit Logs #

Audit Log Viewer Screen #

System Audit Log #

Purpose #

UI — Grid Columns #

Detail Sidebar #

Entry Types #

Object Categories #

Environment Context #

Job Audit Log #

Purpose #

UI — Grid Columns #

Detail Sidebar #

Job Audit Log Folder (Systems Integration) #

Storage Location #

File Format #

JSON Schema #

Example JSON Entry #

Integration Notes #

Summary #