History and audit

History and audit help users trust a record. They answer questions such as what changed, who changed it, when it changed, and which surrounding event explains the change.

The exact history available depends on the record type, enabled features, access rules, retention settings, and the workflow that produced the change.

Activity, history, and audit

These words are related, but they are not identical.

Activity is the user-facing stream of notable events around a record or related workflow. It helps people catch up quickly.

Record history focuses on changes to the record, such as field updates, assignment changes, comments, files, tags, or lifecycle events when those areas are tracked.

Audit information is the governed evidence used to explain important changes. It is especially important for access changes, business facts, responsibility, and process-sensitive operations.

Reference changes after a merge

Open History on a related record whose link was transferred by a merge. When that record type has history enabled, its Update entry shows the old and new link, who changed it, when, and the origin Record merge. Changes to several links or Table cells on that record appear together; Table row IDs and their order stay the same. For an owned Table, open its owning record’s history.

Open the archived original record’s history to read the reason for archiving it. The transfer entry and the Archive entry can show the same correlation identifier when you have access to the merge operation. The reason belongs to the Archive entry and is not repeated on every related record.

Your current record, history, archive, field and target-record access rules still apply. An unavailable reference does not reveal a hidden record’s name or link. If you cannot read the related merge operation, its correlation is omitted while the permitted change and Record merge origin remain visible. Losing access after the merge affects the next read, including after reloading.

This records new transfers after the feature is installed. Older missing events are not recreated; older entries without origin details remain unknown. Disabled history stays disabled, and retention may remove earlier evidence. A transfer’s audit entry does not itself recalculate a custom business summary.

What history can show

Depending on configuration and access, history may include:

• field values before and after a change;
• who created or updated a record;
• when a change happened;
• assignment or responsibility changes;
• comments, file, or tag events;
• archive or restore events;
• actions, workflow, board, or module events linked to the record.

History is most useful when the record type has meaningful fields and clear responsibility. A good record should explain both its current state and the path that led there.

Access-aware history

History follows access rules. A user may be able to open a record but not see every field value that changed. Sensitive fields, restricted linked records, or security-related details may be hidden or summarized depending on the user’s permissions.

This keeps audit useful without turning history into a side door for restricted data.

Retention and expectations

Not every record type keeps the same history forever. Some record types may have audit enabled with long retention. Others may keep less detail because the business object is simple or the organization has different retention rules.

When auditability is important, administrators should configure the record type so important changes are structured, tracked, and visible to the right roles.

History in record and workspace pages

The native history view and supported Workspace UI history component display 25 events initially. Choose 10, 25 or 50 per page and move between pages to read older events. Select an event to inspect available field changes, table row changes, assignments, manual-order changes or business-event details. Table changes and address details open in nested dialogs; close them to return to the event.

Only history and fields that you may read are returned. An empty history means there are no visible entries in that result; it does not prove that the record never changed. Different write paths and record-type settings determine what was recorded.

Who or what made a change

Each event shows its author in the list and its Origin in the event details:

• Person — someone saved or merged the record; a merge is shown as Person · Record merge. When functions derived some of the saved values, Values derived by lists them; the change still belongs to the person who saved it.
• Function, Trigger or Schedule — automation changed the record. The details name the function and its version, the run, and Started by: the person whose action started the automation, such as the user who ran a command or saved the record that started a trigger. A scheduled run has no such person, and neither has automation that another automated step started. The author in the list is usually the system automation account; a function that runs as the current user shows that user. When a command saves several records as one change, each record shows its own event with the same author.
• System — an operation that the system automation account performed, such as a merge that a function ran.
• Not recorded — the event has no origin details. Older events and some saves are recorded this way. It does not mean that the change was made by hand.

The run is shown as an identifier. Workspace owners, administrators and configurators can open it in Function operations; the history itself never shows run logs or data. If a run has since been removed from the run history, the event keeps its origin details.

Automation that creates, changes, imports, archives, restores or deletes a record does not start that record’s trigger functions; saving a record yourself still does, and so does a merge or a change of responsibility.

Archive, restore and delete events show the reason entered for the operation, including a group action on several records and a record merge, which archives the merged record. A record changed by a cascade shows the reason of the operation on the original record, or states that the reason is hidden if you cannot read that record’s history or the record no longer exists. Reason not saved marks an event recorded before reasons were stored. After a record is permanently deleted, or when its record type does not keep change history, workspace owners and administrators can still read the reason in Administration > Audit; filter by record type or record ID to find it. For a record you cannot open, the audit shows only its type and ID and hides the details of events about it.

When a save response is lost

A custom page or integration that saved an operation handle before sending can check its own confirmation. Saved, result unavailable means the operation committed, but current access or deletion prevents showing its records. No confirmation does not mean it failed: the operation could still finish or its receipt could have expired. A failed check is also inconclusive. Do not submit another save automatically. Ask the page owner to investigate. This API addition alone supplies no recovery screen for ordinary forms.

Where to go next

• Read Object collaboration for collaboration context around records.
• Read Access and governance for roles, Security Statements, responsibilities, field access, and audit trail concepts.
• Read Data structure when you need to understand how record types are configured.