Audit Logs
Jetveo can automatically record the change history of selected entities — every create, update, and delete — without writing any code. You opt-in per entity and choose what is tracked; the platform stores the history and you visualize it in the app using the Audit Timeline component.
Audit tracking is configured on the Audit tab of the entity detail in the App Builder.
Enable Audit Tracking
Open the entity, go to the Audit tab and turn on Enable audit tracking.
Once enabled, choose the scope:
- Track all fields – every attribute and reference of the entity is tracked.
- Select fields – only the attributes and references you check are tracked. Both lists include members inherited from Aspects (the originating aspect is shown next to the member).
Track Child Changes
Changes made to child instances can be folded into the parent's history, so you see them on the parent's timeline.
Under Track child changes, enable the child references you want to bubble up. Only Composition (1 : N) and Aggregation (0..1 : N) references can be enrolled. For each enrolled child you again choose All fields or Select fields (the listed attributes of the child entity).
Adding, removing, and updating a child are all recorded on the parent. Bubbling is one level deep — a child's own children are not folded into the grandparent.
Access
Audit history can contain sensitive information, so reading it is gated.
In the Audit access condition field, write a boolean expression deciding who may read this entity's audit log:
ctx.User.HasClaim(App.Security.Claims.AuditViewer)
Leave it empty to allow all authenticated users. The condition is evaluated before any audit data is returned to the app.
Showing the History in the App
The history is displayed by the Audit Timeline component. Place it on the entity's detail page and bind it to the entity instance — no code required. It loads the history on demand (paged, newest first) for the bound instance.
What you see on the timeline:
- Entries grouped by day, marked Created, Updated, or Deleted.
- For updates, each changed field shown as
old → new(old value struck through in red, new value in green). - Reference changes (Many-to-Many, codebook collections) shown as colored tags — added and removed values for the same reference on one line.
- A newly created child shows the initial values of its tracked fields.
- Date/time values shown in the viewer's local time zone and locale.
- The operation that made the change shown subtly at the end of the line — a command or service name, or Manual change for an ordinary edit through the UI.
What Is Recorded
| Event | Stored |
|---|---|
| Created | The instance was created (no field snapshot). |
| Updated | The fields and references that changed, with their old and new values. |
| Deleted | The instance was deleted. |
Notes:
- Display values are snapshotted. Referenced entities are stored by their display expression and codebooks by their Code at the moment of the change, so the history stays readable even if the referenced record is later renamed or deleted.
- Within one save, a reference value that is removed and added back (or vice versa) cancels out and is not logged.
Performance
Audit tracking adds a small cost to each save that contains tracked changes: alongside the entity changes, the platform writes one audit record per changed audited entity, within the same transaction. For typical saves (a handful of entities) this overhead is negligible.
The cost scales with how many audit records a single save produces, so it becomes noticeable on bulk operations that create, update, or delete thousands of tracked entities at once (e.g. data imports) — the same bulk operation over an audited entity takes meaningfully longer than over a non-audited one.
Keep it in check:
- Audit is opt-in per entity, and within an entity per attribute and reference — track only what you actually need history for.
- Entities without audit enabled are unaffected, and a save that changes nothing tracked skips the audit step entirely.
- Be mindful when enabling audit on entities that are written in large batches.
Limitations
- Bulk database operations (
ExecuteUpdate/ExecuteDelete) bypass the change tracking and are not audited. - The Audit Timeline is bound to a live instance, so it cannot show the history of an already deleted instance. (A cross-entity browse page covering deleted instances is planned.)
- There is no automatic retention/cleanup — the audit log grows with the tracked changes.