Record history and restore
Record history keeps what a record looked like before each change. It answers "what was this before?" and lets you put a record back. It is separate from the audit log: the log says who changed which record and when, by field name only, while the history holds the values themselves.
Switching it on
Record history is off by default. Switch on Keep record history in the audit settings of each organisation that should have it; the health care profile switches it on and keeps it on. History begins with the first change made after that. Changes made earlier were not kept and cannot be recovered. Once an organisation keeps history, every change to its records is captured, whether it was made in the dashboard, by a client on the online booking page, or by an automatic job.
Who created and changed a record
Most record dialogs, the detail rows of orders, payments and wallet entries and the expanded journal rows show one line at their bottom-left edge: "Created", the date and time and "by" the creator, then "· Changed", the date and time and "by" whoever changed it last, for example "… · Changed … by System (reservation expired)". The second half appears only once the record has been changed after it was created. On a narrow screen the line is shortened; point at it to read it in full.
Lists can show the same facts as columns: the Columns button at the right end of a list's header row offers Created, Created by, Changed and Changed by. Your choice is remembered for that list on this device.
The names come from the database, so every user sees the same name for the same person, whatever their device has synchronised:
| Shown as | Who it was |
|---|---|
| The person's name | A member of your tenant, also one who has since left it. |
| go flow admin | go flow staff working in your tenant. |
| Unknown user | A user who is not a member of your tenant. |
| (client) | A client, on the online booking page. |
| Online booking | The online booking site acting on its own, not on behalf of a signed-in client. |
| System (…) | An automatic job, named by what it did: reservation expired, cancellation processed, no-show, post-visit follow-up, promoted from the waitlist, reminder scheduled, order activated, retention period ended, payment reconciled, refund reconciled, messaging, invoicing or alerts. Records an automation changed before these names existed show System (booking automation). |
While you are offline the names cannot be looked up and stay empty; they appear when the connection returns.
Opening a record's history
Under the form of most record dialogs, in the detail row of orders, payments and wallet entries, in the expanded rows of a client's Journal tab and of the Journal page, and in the user dialog, the line described above ends with a History button when history is available. It appears when all of these hold:
- the record has been saved at least once;
- the record's organisation keeps record history;
- you hold the Audit log right on your tenant (see Audit log).
In the user dialog the history lists the changes to the user's rights in your tenant; a user's rights cannot be restored from it. In the journal rows, History is offered for a booking (the client's place in a session), a journal note, an order, a payment, a wallet entry and a voucher. A message row shows who created and changed it, without a History button.
You can also open it from the audit log: expand a row that names a record and choose History. The button appears for a record type that has a history, and only when the row's organisation keeps record history, the same check as for the line at the bottom of a record. For any other row there is no button, because nothing was kept.
The history opens in a panel from the right edge titled Record history, with the record's name at the top.
Reading the history
The panel lists the record's changes, newest first. Each is a collapsed entry titled Changed with its date; beneath the title are the version number and who made the change. The newest entry is open when the panel loads.
Open an entry to see what that change did. Every changed field is one row: the field's name, its old value, an arrow, and its new value. A value that was empty or did not exist reads (none), and yes/no fields read Yes or No. A change that deleted the record carries a Deleted chip.
A few rules help in reading it:
- An entry holds the record as it was before its change. Restoring an entry therefore returns the record to how it was just before that change.
- Only the newest 100 versions are shown, and a notice says so when there are more.
- A record with nothing earlier to show reads "No earlier versions". History starts with the first change after record history was switched on.
- A record that has no history at all reads "No history is recorded for this record."
Who made a change
Each entry names who made the change: a member of your tenant by name, a client acting on the online booking page as Client, and every automatic job as System (the line at the bottom of the record names which automation made the last change, see Who created and changed a record). go flow staff appear as go flow support, never by name, in English whatever language you work in.
Masked values
Some values are not shown to everyone. A masked value appears as a lock chip reading Masked and is never present as text, so it cannot be selected or copied.
- Answers of protected fields (fields with read logging, see Audit settings and the health profile) are masked unless you also hold the Clients right on that organisation. This applies to every field whose Read logging is not Not logged, whether or not the organisation logs reads. With that right the values appear and a notice at the top says "This view shows values of protected fields. Showing them was recorded in the audit log." The showing is recorded as Protected client fields viewed (
client.read.sensitive) for the fields that are logged now: those set to Always logged, and those set to Logged when opened while the organisation logs reads (see Read logging). - A notice reads "Some values are masked. They are shown only to users who may read client data, and that reading is logged." whenever masked values are present.
- An organisation's credentials, such as payment or messaging keys, are always masked.
- PINs, access tokens, passwords and payment-provider tokens are never shown, not even masked.
- A field set to Latest value only shows only its current value; in earlier entries it is masked. A field set to No history is left out of every entry.
Restoring a version
- Open the entry you want to go back to.
- Choose Restore this version. Beneath the button a note reads "Brings the record back to how it was before this change. The current values are kept as a new version, so a restore can be undone."
- Confirm the question that asks whether to restore the record to how it was before the change on the entry's date.
The panel then reports "Version n restored." and reloads, with the restore as its newest entry. If the record already held those values, you get "The record already holds these values; nothing was changed." and nothing is written.
What a restore does:
- It compares the record with the entry and writes only the fields that differ. Choosing an older entry also undoes every later change to those fields.
- It stamps the record as changed by you, now, and saves it like any other edit. Other people's dashboards pick it up through synchronisation, as with any edit.
- A restore is itself a version. The values it replaced are kept as a new entry, so you can undo a restore by restoring the entry before it.
- It is recorded in the audit log as Earlier version restored (
entity.restore), with the version in Details, in the Data category.
Who may restore
You need the Audit log right and the right to change that kind of record, at Manage:
| Record | Right needed besides Audit log |
|---|---|
| Clients, session participants, journal entries | Clients or Configuration & settings |
| Sessions, promotions, booking templates, fields, feedback forms and questions, message templates, organisation settings | Organisation or Configuration & settings |
| Resources, resource treatments, resource integrations, treatments, products, texts | Configuration & settings |
Manage on a single resource (under Resources in the user's rights) also lets you restore that resource, its resource treatments and resource integrations, and its sessions and their participants. Without any of these rights the panel shows the reason (in English) above the entries, and Restore this version stays disabled.
What can be restored
| Restorable | Shown but never restored |
|---|---|
| Clients, journal entries, session participants, sessions (appointments), resources, resource treatments, resource integrations (settings only), treatments, products, promotions, booking templates, fields, feedback forms and questions, message templates, texts, organisation settings. | Money records: vouchers, wallets, orders, payments and refunds. Users' rights. |
For these two groups the panel shows why (in English), and Restore this version stays disabled:
- Money records change only through their own actions (refund, adjustment, payment). A money record restored outside its own action would break balances, refunds and receipts.
- A user's rights are granted in the user dialog, which limits them to the granter's own rights and updates sessions that are already signed in. Restoring them directly would bypass both.
A record you deleted is normally only marked as deleted, so restoring a version from before the deletion brings it back. A deleted record no longer appears in its list: open its history from the deletion's row in the audit log. This is also how a client deleted with Delete the client record comes back; a client whose personal data were erased cannot, because the erasure removes its history (see Erase a client). Restoring a session leaves its participants as they are.
What is never restored
A restore never touches:
- the record's identity, its organisation and its creation details;
- on a client: the PIN and its expiry, a pending email change and the failed-sign-in and lockout counters;
- on a participant: payment and refund markers, the link to its order, its appointment, number of places, claim and reservation codes and cancellation timestamps;
- on a session: the number of places booked and the links to an external calendar;
- on a promotion: how often and for how much it was used;
- on a resource integration: its credentials and synchronisation state;
- on an organisation: whether it is deleted. Its settings are restored, and its credentials are kept as they are stored.
On clients, participants and journal entries, a field marked No history keeps its current value.
When a restore is refused
The panel shows the reason in the confirmation dialog. The common ones are:
- the record no longer exists (only records that were marked deleted can come back);
- the restore would move a participant or session into or out of a cancellation;
- the record belongs to something that is gone or deleted: a participant whose session or client was deleted, a journal entry whose client was deleted, a session whose resource was deleted, and so on;
- the restored settings break a rule, for example a field setting the health care profile forbids. The message lists each violation;
- another record already holds a value that must be unique, or the record points at one that no longer exists. The message names the field.
Retention
History is kept for the retention period of the organisation's audit settings, 12 to 120 months. Older versions are removed automatically by a daily clean-up and cannot be restored afterwards. Lowering the period removes the older versions at the next clean-up. Switching Keep record history off stops new versions from being kept; the versions already kept stay until the period removes them, but the History button is no longer offered while history is off.
Erasing a client removes the history of the client, its bookings and its journal entries at once. A field's Retention (months) works differently: it clears the answer from a deleted client, but the earlier versions in the history keep the answer until the period removes them.