Activity history

Activity history shows performed changes, not attempts or diagnostic logs. It includes committed workspace setup changes, including pending invitations, account setting changes, acknowledged parameter writes, device API calls, and which billing account pays for the workspace. It does not include reads, page visits, polling, telemetry, stored readings, failed or cancelled requests, permission denials, or balance changes, which the billing account’s ledger records. Deleting stored readings is recorded, though: each deletion or retention run is one entry with a Delete of the Readings of every parameter it touched and the number of records it removed; stored data explains them. A device API call is the exception: every call that passes its checks is recorded as a Call of the Device API target, with its operation, input, and outcome, even when the device refuses it or does not answer, because the device may have acted. Input values that the device’s manifest redacts, such as passwords, are left out.

Workspace history is on Setup → Activity history. Only editors, admins and owners can open or export it. The page filters by time, actor identity, actor type, channel, action type, and target. Actor types are a user, the assistant, an API key, an automation, whose parameter writes show under its name with the Automations channel, and the system. Entries from one action are grouped together. Each entry takes one line: the time, who acted, the action, the target, and the channel. Where the page is too narrow for these columns, such as on a phone, each entry stacks into three lines: the target, then the action and channel, then the time and actor. The target also shows the written value of a parameter write, or the field that changed with its old and new value; a change to several fields lists their names. An entry with several kinds of action, such as a create and an update, shows the first with a count of the others. Selecting an entry compares every changed field before and after. All matching history exports as JSON or CSV. Exports are explicitly marked when the 10,000-event safety limit is reached. Parameter-write entries retain the requested value and source-acknowledged details; a multi-address write whose acknowledgments were partial is marked Partial. Times use the browser timezone and the fixed YYYY-MM-DD HH:mm:ss format. A new entry normally appears within a second of the change. If history storage is briefly unavailable, the page cannot load; no entries are lost, and they appear once it recovers.

Checkpoints

A checkpoint marks a workspace’s setup at one moment. People and the assistant take named checkpoints, which stay until someone deletes them. The system also takes automatic checkpoints: before a CLI push or upload that changes the setup (Before push, or Before import for an uploaded archive or imported changes), before the assistant’s first setup change in a turn, before applying a parameter template, before a bulk delete, and once a day after the workspace’s local midnight when its setup changed. Automatic checkpoints are deleted after 30 days.

In Setup → Activity history, checkpoints appear as highlighted markers among the entries. A marker sits where its checkpoint falls in the order changes were saved, so the entries above it happened after it, even when a change and its checkpoint share a second. Each marker shows the name or kind, when it was taken, who took it (a person, the assistant working for a person, or the system), and the reason when one was given. Expand a marker to list the setup items created, changed, or deleted after it, up to the next checkpoint shown or the current setup; parameter writes and other non-setup activity are not part of this list.

The page switches between All activity and Checkpoints only. The checkpoint filter shows Important checkpoints (named, and the kinds before a push, assistant changes, a template, an import, or a revert) or All checkpoints. The page address keeps both choices, so a link opens the same view. The period filter also limits checkpoints; the other filters and exports apply to entries only.

Create checkpoint names the current setup, with an optional reason. A named checkpoint’s marker menu renames or deletes it; deleting a checkpoint changes neither the setup nor the activity history. Automatic checkpoints cannot be renamed or deleted. Every checkpoint’s menu also offers Revert to this checkpoint; see Reverts. The hmi checkpoint commands of the CLI and the assistant work with the same checkpoints; the assistant asks before it deletes one or reverts to one.

Reverts

A revert returns the workspace’s whole setup to how it was at a checkpoint, or at an earlier moment: dashboards and their files, endpoints, edge programs, the parameter tree, report presets and comments, alarm rules, automations, uploaded files, and the workspace’s name, timezone, and location. It is saved as a new setup revision, so nothing in the history is lost. Setup, the hmi checkpoint revert command of the CLI, and the assistant can revert.

• Who: editors, admins, and owners. A revert that would change the workspace name, logo, or favicon needs an admin or owner, as changing them in settings does. For an editor it stops with push_admin_required and changes nothing.
• Undo: right before it changes anything, the revert takes a Before revert checkpoint. Reverting to that checkpoint returns to the state before the revert.
• Identity: items keep their identity. A deleted parameter comes back as the same parameter, so its recorded readings show again in charts and reports. Readings that were deleted, by people or by retention, stay deleted.
• Constant values come from the checkpoint. A revert to a moment takes them from the nearest earlier checkpoint, which the summary names. When no checkpoint is that old, constant values stay as they are.
• PIN connections come back exactly. A PIN connection deleted since is recreated with its id, and its device binds to the workspace again, so the parameters and programs that use it work again. A recreated MC252 must be confirmed on site first, by pressing R on it or entering the code from its screen, as when it is connected. An MC252 still connected to this workspace under a newer connection needs no confirmation. A PIN connection added since is deleted.
• Setup older than activity history that has not changed since stays as it is.
• Running systems follow. Polling picks up the reverted parameters and endpoints on its own. Changed edge programs are deployed to a device whose auto-sync is on. A device with auto-sync off keeps its programs until they are synced.
• Local checkouts get the reverted setup on their next hmi pull. Local edits made before the revert surface as conflicts.
• All or nothing: a revert restores the exact setup or nothing. When items of that setup can no longer be read, because the account that wrote them was erased, the revert lists them and is refused. A revert also refuses a setup that would no longer be valid, for example an automation that a lower automation limit no longer allows; the message names the item.
• Concurrent changes: if the setup changes after the revert summary was shown, the revert stops with “The setup changed” and changes nothing.
• Time: --at takes a local time in YYYY-MM-DD HH:mm:ss and includes changes saved during that second.
• Assistant: the assistant shows the same summary and asks before it reverts, unless Setup changes is auto-allowed in the chat. It cannot confirm devices, so a revert that recreates an MC252 is done in Setup or the CLI. Without a terminal, the CLI stops and names the devices to confirm.

Account history

Account settings → History shows personal profile and credential history. Credential entries say that a credential changed but never expose authentication secrets, hashes, tokens, or API-key material. This page also links to deleted-workspace history owned by the current user. Deleting a workspace does not delete its activity history.

Undo and deletion

History entries cannot be undone one by one. A revert returns the whole workspace setup to an earlier state (what it covers). Parameter writes, device API calls, membership changes, and account changes are not part of the setup and cannot be reverted.

Admins and owners can delete workspace history older than 30 days, or set it to expire, on Setup → Stored data (manage stored data); what rebuilds the setup at retained checkpoints is kept, and the deletion itself is recorded. Deleting an account removes that account’s personal history and the archives of its owned workspaces. Activity in workspaces owned by other people remains, with the deleted account’s identifying attribution removed.