Change History & Undo

Knowledge ERP keeps an audit trail of changes across all major records, so you always know who did what and when — and can reverse it if needed.

What's tracked #

Edits to major records (inventory, sales, purchasing, rentals, CRM, and more) are recorded as change groups: a logged action capturing the user, the timestamp, and the before/after of each field that changed. Related changes made together are grouped, so a single business action reads as one entry rather than a scatter of unrelated edits.

Your account settings are tracked the same way, including a rename of your business under Account Settings → Branding — that name is what your customers see in their inbox, so who changed it and when is worth being able to look up.

The settings that shape how your business runs are recorded the same way: appointment types and their questions, opening hours for a location, staff hours and time off, automation rules, custom fields, and a survey's own settings. Editing one records who changed it and what it was before, and each has a History tab. An automation rule's actions are recorded as changed without their contents, because a webhook action can hold a secret. A save that changed an automation rule's actions cannot be undone.

Deciding an approval request, sending a pre-visit form or a survey invitation from a record's page or over the API (and canceling one over the API), logging a call or meeting on a customer, and requesting a data export are recorded too, with who did it. A survey sent to many people at once is recorded as one entry, with who started it. A form or survey sent automatically is recorded only when it happens as part of something a person did. The links that open a form or a survey, and the email addresses on these records, are not recorded. A decision on an approval request cannot be undone from History. If an approval rule created a request as part of a change (such as creating or submitting a purchase order), undoing that change needs permission to delete approval requests, and is not possible once the request has been decided. Undoing a survey invitation sent automatically as part of a change needs permission to delete survey invitations.

Notes and tasks on a customer, a person's reorder digest preferences, and the schedules of emailed reports are recorded the same way, with who changed them and what they were before. A customer's notes and tasks are in that customer's History; the digest and the schedules are in the Change Log.

Quantities counted on a stock count, whether entered on the scan page or on the count sheet, and the parts a unit was built from are recorded the same way, in the History of the stock count and of the unit. Mark All as Expected sets every line that has not been counted yet to its expected quantity, and is recorded as one entry that lists every line it changed. An entry that changes more than 1,000 lines is recorded in full but cannot be undone.

Moving a rental agreement through its lifecycle from its page (Reserve, Pick Up, Return, Close, Cancel) is recorded with who did it, as the same moves over the API already were. An entry that changes a rental's status cannot be undone or redone from History, because each of those buttons does more than change the status: undoing a Cancel, for example, would put the rental back in Reserved without checking the equipment is still free.

Your connections to other services are recorded too: Shopify, WooCommerce, QuickBooks, ShipStation, Twilio, your payment gateway and email accounts. Connecting one, turning a sync switch on or off, replacing a webhook signing secret and disconnecting one each record who did it. Keys, tokens and secrets are recorded as changed, without their values, so these entries are history and cannot be undone. They appear in the Change Log.

Roles and permissions #

Who is given what is recorded as well: a role ticked or unticked on a person's page, an extra permission, a permission taken away from somebody, the permissions on a role in the role editor, a role given or taken away on the role's own tabs, and a person placed in a role at a location. Each is in the Change Log, in the entry of the save that made it, beside whatever else that save changed. Creating, renaming, duplicating, deleting and restoring a role are recorded too.

These can be undone and redone like other changes, with one rule: an Undo or Redo that hands access over asks what handing it over asks. Undoing the removal of a role or a permission, redoing one that was given, and undoing a permission taken away from somebody all give access back, so they need you to hold every permission involved yourself, and to be allowed to edit the person (or, for a role's own permissions, to edit roles). Undoing the removal of somebody's place at a location, or a change to which role they hold there or where, also needs you to hold that role's permissions and the permission to edit users (update_users) at that location. Undoing the removal also needs the permission to restore users (restore_users). Undoing something that takes a role or a permission away does not ask about the permissions involved, only whether you may edit the person or the role. Taking somebody's place at a location away, by Undo or Redo, needs the permission to delete users (delete_users) at that location. See You cannot pass on what you do not hold.

An Undo or Redo that would leave your account with nobody who can manage users is refused, and nothing is changed. So is undoing a removal when the same role or permission has been given again since.

Roles and permissions given when your account is set up, when you register, to Pelton support staff, and by an import from an earlier system are recorded, and cannot be undone. A role that comes with your account or with a module starts with its template's permissions: the role's creation is recorded, and its starting permissions are not listed one by one. Every change made to the role after that is, except on the Admin role: it is kept holding every permission, so its permissions are not recorded.

Viewing history #

Records expose their change history, letting you trace how a value got to where it is — useful for answering "who changed this price?" or "when did this status flip?" without guesswork.

Undo and redo #

Most tracked actions can be undone — putting the record back to its prior state — and redone. Changes are grouped, so Undo covers the whole action rather than one field at a time, which makes reversing a mistake one step instead of many.

On records that keep History, deleting a record, restoring it, and deleting it permanently from its page or a list are recorded too, with the person who did it. A delete or a restore can be undone from History; a permanent delete cannot, because the record is gone.

Undo puts back everything in the action that it still can. If part of it can no longer be put back — usually because one of the records has been changed since — Undo says Unable to Undo, and the rest of the action stays put back. An action can cover several records, so check the records it touched before trying again, not only the one you pressed Undo from.

If other people keep changing the same records while you press Undo or Redo, it may not finish at once. You'll see Undo in progress (or Redo in progress), and the entry offers no Undo or Redo until it is done. A notification tells you when it has finished, or how far it got.

A deleted record whose barcode now belongs to another record, or a deleted unit whose serial number another unit of the same product now has, does not come back on Undo: the entry offers no Undo and says which barcode or serial number is in the way and, for a barcode, which record holds it. Change one of them, then Undo again.

A record whose barcode now belongs to another record is not brought back by Restore either. On the record's own page, Restore says which record has the barcode now. A bulk Restore brings back the records it can and lists each one it left deleted, with the reason.

A customer's answers on the pre-visit form are recorded in the history, attributed to the customer, but cannot be undone: Undo says Unable to Undo. To change an answer, edit the field.

A purchase order moving into or out of Draft, such as submitting or unlocking it, is recorded in the history but is not undone or redone from it: that entry offers no Undo or Redo for anything in it, and an Undo from the order's own page says Unable to Undo. Use Submit to Vendor and Unlock for Editing instead: submitting checks your purchase limit, and unlocking records who unlocked the order and why. Moves between Submitted, Partially Received and Received can still be undone, so a mistaken Close PO can be put back.

Passwords and two-factor #

A change to a password or a second factor is in the history, and never what it was or is. The history says changed Password, changed Authenticator app, changed Recovery codes or changed Emailed code, and who made the change.

These are recorded: someone setting a colleague's password or using Reset two-factor on the Users screen; a person changing their own password on their profile; a password reset from the sign-in page; a colleague choosing a password when they accept an invitation; and a person setting up, regenerating or turning off their authenticator app, turning the emailed code on or off, or using a recovery code to sign in.

An entry that holds one of these can't be undone, and neither can anything else changed in the same save. Anything else saved on a person's own profile, such as their name, is in the history too.

Who can see a person's history #

A change to a person, such as a rename, a password or a two-factor reset, or a role or permission given to them or taken away, is in the history only for somebody who can view the change log and can see that person. That is an administrator, anyone allowed to view users across the account, anyone allowed to view users at one of that person's locations, and the person themself, for their own history, if they can view the change log at all. Somebody with no location assigned is seen only by administrators, by those allowed to view users across the account, and by themself.

This applies to the History tab and to the Change Log. An entry that changed several records at once is shown only to somebody who can see every person in it. Once the person an entry is about no longer exists at all, the entry is shown only to administrators and to those allowed to view users across the account. So is an entry that gave or took away a role or permission, or placed somebody at a location, once that grant or placement no longer exists at all. This happens, for example, when a person or a location is permanently deleted. Opening a colleague's record is not affected.

Attribution beyond the UI #

Changes made through the REST API are attributed to the user — or the service account — that the token acts as, plus the token's name. Support-team actions are labelled too, so the trail names a real actor no matter how a change was made.

A shipment imported from ShipStation is labelled ShipStation instead of a person. It appears in the History of the sales order it shipped, and can't be undone from there: the shipment already happened.