Short answer

Two different things get called "history", and it's worth separating them. The work history is complete and visible: every inspection, defect and job ever raised against an asset is listed on that asset, dated and attributed, and that is what you show an auditor, insurer or risk assessor. The field-level change history is captured but not yet shown to you. On screen today you get who created a record and who last updated it, not a line-by-line log of what changed. The underlying log does exist, so nothing is being lost while we work on surfacing it.

Detail

What you can see today

Every asset and every task ends with a line reading who created the record and when, and who last updated it and when. Those four values are also available as columns on the asset and task lists and as filters, so you can answer questions like "what did we add last month" or "which records has this person touched" without opening anything.

What "audit trail" usually means in practice

When a council needs to demonstrate that checks were done, the thing that carries the evidence is the asset's Tasks tab: the run of inspections, defects and jobs against that specific item over time, each with its date, its assignee, its checklist answers and its photos. A failed check reads as a chain, from inspection failed, to defect raised, to the jobs that fixed it, to the defect resolved. That is the record an external assessor asks for, and it is complete.

So if the question behind "can we see the full history" is can we prove this extinguisher was checked every month and that the one fault got fixed, the answer is yes, and it does not depend on the change log below.

What isn't shown yet

What you cannot currently open is a per-change log: this field was X, someone changed it to Y at this time. Civic.ly does record that behind the scenes for changes made through the app, so the history is accumulating now rather than starting from the day the screen appears. It simply is not exposed in the web app or the mobile app yet.

What's coming

Two additions are planned, neither of them live yet:

  • Surfacing the change history in the app, so the log described above becomes readable.
  • A "completed by" and "completed at" on tasks, so you can see who actually carried out an inspection rather than only who last edited the record. This is the more useful of the two for most councils, because the person who ticks a check in the field and the person who tidies the record up afterwards are often not the same person, and today only the second one is visible.

Watch-outs

  • Don't rely on "last updated by" to tell you who did the work. It tells you who last saved the record, which may be an administrator correcting a typo weeks later. Until completed-by ships, the assignee plus the completion date is the closer read, and the checklist answers are the actual evidence.
  • A deleted task is not recoverable from the screen. Assets can be restored, tasks cannot, so treat deleting a task as permanent and cancel it instead when you want the record kept.
  • Bulk changes are the weak spot. Where a single action updates many records at once, the change log is less complete than it is for one-at-a-time edits. If you need a defensible record of a mass change, note what you did and why in the affected records rather than relying on the log.
  • "Audit trail" in the help centre usually means the task history, not the change log. If you are reading about audit trails elsewhere in these pages, that is the sense being used.