Logs

Logs Overview

The platform keeps several logs rather than one, because they answer different questions and have different volumes and retention.

Where to find it

Architect Panel → Activity:

• Activity Log — changes to data
• Record Read Log — who read what
• Audit Chain — tamper-evidence over the audit entries
• Error Log — what went wrong technically
• E-mail Log — what was sent, and whether it went
• SMS Log — text messages sent
• Calls — telephone activity
• Correspondence — letters and documents sent
• Satisfaction — survey responses received

Choosing the right log

• "Why is this record like this?" — Activity Log.
• "Who has seen this?" — Record Read Log.
• "Can I prove the history is intact?" — Audit Chain.
• "Why did this page fail?" — Error Log.
• "Did the customer get the e-mail?" — E-mail Log.
• "Did the text message go?" — SMS Log.
• "What contact have we had with them?" — Calls and Correspondence.

Most wasted investigation time comes from starting in the wrong one. Deciding what kind of question you are asking first will usually save more time than any amount of skilled searching afterwards.

They are all under Activity

Every log listed above is in one place in the Architect Panel, under Activity. There is no separate Logs section — if you are looking for one, this is where the logs are.

Logs answer different questions from timelines

A record's activity stream is the business history of that record, written for the people working on it. These logs are technical and operational records, written automatically and read by administrators.

A customer asking "what is happening with my case" is answered from the timeline. A colleague asking "why does this field say that" is answered from the Activity Log.

Volume differs enormously

Reads outnumber changes; changes outnumber errors; errors outnumber almost everything else on a healthy system. That shapes how each is used — the error log can be read; the read log must be filtered.

Retention is a decision per log

The right retention differs by log. Errors are useful for weeks. Audit entries may be needed for years. Message logs contain the content of communications with people, which brings its own obligations.

Set each deliberately. The default of keeping everything forever is both a storage problem and, for logs containing personal data, a compliance one.

Start with the error log after any deployment

It is the cheapest possible check, and a new error type appearing on the day of a release is the clearest signal you will get. Making it routine turns a class of problem into something found before it is reported.

Worked example

A customer says they never received their invoice. The E-mail Log shows it sent successfully to an address ending in a typo. The Activity Log shows that address was entered three weeks earlier by a member of staff, replacing a correct one. Two logs, one question each, and the answer is complete — including how it happened.

Recommendations

• Decide what kind of question you have before opening a log.
• Check the error log after every deployment.
• Set retention per log, not globally.
• Use timelines for people, logs for administrators.

Where Each Log Lives

Every log the platform keeps is a set of ordinary database rows, reachable from the Architect Panel under Activity, and queryable and exportable like any other data.

Where to find it

Architect Panel → Activity:

• Activity Log — changes, with before-and-after row data and chain hashes
• Record Read Log — reads, with record IDs, row counts and context
• Audit Chain — the chain head, seal and verification state per datastore
• Error Log — type, message, URL, stack trace, user agent and IP
• E-mail Log — account, recipients, subject, body, attachments and result
• SMS Log — number, message, provider message and request identifiers
• Calls — telephone activity
• Correspondence — letters and documents sent
• Satisfaction — survey responses

Everything is in the database

There is no split where some logs live on disk and others in tables, and nothing is written to an external logging service. Stack traces are stored in the error log row itself rather than in a file alongside it.

The practical consequences are good ones: every log is included in the normal database backup, every log can be queried and filtered the same way, and there is no second retention regime to manage or forget about.

What that means for exports

Because each log is a datastore, the ordinary export applies. An extract for an auditor, a regulator or an investigation is produced the same way as any other data export, with the same permissions governing who may take it.

Log contents are sensitive

Worth stating plainly, because it is easy to think of logs as technical rather than personal data:

• The Activity Log holds complete before-and-after copies of rows — including any personal data those rows contained.
• The E-mail Log holds subjects, bodies and attachments — the actual correspondence.
• The SMS Log holds message text and telephone numbers.
• The Error Log holds URLs and stack traces, which can contain identifiers and occasionally submitted values.

Access to logs should therefore be restricted like access to the underlying data, not more loosely because they are "just logs". A read-only auditor account with access to the activity log has access to a copy of everything.

Retention applies here too

Because logs hold personal data, they fall within retention and disposal like anything else. A policy that carefully disposes of case records while keeping an audit log containing full copies of those records has not achieved what it set out to.

Backups include logs

Which is usually what you want, and is worth knowing when estimating backup size — the activity log on a busy system is frequently larger than the data it describes, because it holds two copies of every version.

Before you query directly

Reading log tables with SQL is legitimate for analysis. Writing to them is not: the audit tables carry chain hashes, and any direct modification breaks the chain and cannot be undone.

Worked example

Preparing for an information-rights audit, an administrator lists what personal data is held. Alongside the obvious datastores they include the activity log — which holds copies of every version of every customer record — and the e-mail log, which holds the correspondence. Both are given explicit retention periods and their access is narrowed to two named administrators.

Recommendations

• Treat logs as personal data when they contain it, which is most of them.
• Restrict log access as tightly as the underlying data.
• Include logs in retention, not just business records.
• Never write to audit tables directly.