Audit Trail

Use the Audit Trail to review changes across the workspace: who did what, when, and through which channel. The audit trail supports accountability, compliance evidence, and troubleshooting of unexpected changes.

Every record in the workspace carries an audit trail and field-level provenance. This applies to products, models, batches, items, DPPs, components, events, documents library, suppliers, and supplier requests.

What is tracked

Typical actions recorded include:

• Models created, edited, published, or unpublished.
• Batches and items created or updated.
• Events added, edited, or removed.
• Components and supplier requests submitted or revised.
• Documents uploaded or replaced.
• Access Keys created or revoked.
• Role or permission changes.

For each field that is created or updated, the platform also stores the following provenance metadata:

• Source type – supplier_user, internal_user, or external_api.
• Source ID and name – the identifier and display name of the user, supplier, or external system that submitted the value.
• Input method – manual (UI entry), api, or import.
• Timestamp – the moment the value was submitted, in UTC.
• Previous and new values – the value before and after the change.
• Field-level metadata is versioned so the full history of a field can be replayed.

Where data can come from

Source	How provenance is captured
Internal user (UI)	Source type internal_user, input method manual. The user ID and display name are stored with every change made through the DPP Manager.
Supplier user	Source type supplier_user, input method manual. Captured on new component submissions and on supplier revision or edit flows.
External API	Source type external_api, input method api. The external system ID or label (for example, an ERP or PLM integration name) is stored with every API-driven change, with a server-side UTC timestamp.

Open the Audit Trail

1. Open Settings › Audit Trail from the left navigation.
2. The table opens with the most recent changes first.

The table shows the following columns:

• Target – Entity type and target name (for example, Model: Polka Blouse).
• Action – Create, Update, Delete, Publish, Unpublish.
• Method – manual, api, import.
• Member – The user or external source that performed the action.
• Timestamp – Sortable, defaults to most recent first.

Filters are available for Timestamp, Action, and Member. The table supports pagination, page-size selection, and sorting by timestamp.

Entity history view

Each entity has a dedicated History view accessible from its detail page (for example, via a View History action). It applies to:

• Model, Batch, Component, Document.
• Supplier, Supplier Request.
• Event.
• Team, Access Key, Roles & Permissions.

The history view is organised into two areas:

• A summary card at the top with the entity information and metadata, plus device and network details when available.
• A version history below with a field-level change breakdown. Each entry includes the action type, user name, source type, input method, timestamp, and the previous and new values.

Field-level diffs are visually distinguishable (old vs new value), and the source type is shown as a badge.