Change history
An audit trail should let someone reconstruct a meaningful change after the people involved no longer remember it. That requires more than an error log or a timestamp on the current record.
PHPRunner includes audit logging for login activity and table changes. The design decision is choosing which actions and field values are important enough to preserve—and who is allowed to see that history.
Quick answer: Record the actor, time, action, table, record key, and—for important edits—the old and new values. Log business events that may need explanation later, protect the history from ordinary changes, and exclude secrets or sensitive values that should not be copied into another storage location.
An application log helps operate software; an audit trail explains changes to business data.
Technical logs may contain stack traces, request timing, service failures, and diagnostic messages. They are useful for developers and administrators but often cannot answer “Who changed this customer's credit limit?” or “What was the previous approval status?”
An audit trail organizes events around users, records, actions, and values. It should remain understandable without replaying raw HTTP requests or reading application source code.
A field value without a record identity or actor is rarely useful evidence.
| Audit element | Question it answers |
|---|---|
| Timestamp | When did the event occur? |
| Authenticated user | Which account performed it? |
| Action and table | Was a record added, edited, deleted, or viewed? |
| Record key | Which business object was affected? |
| Old and new values | What actually changed? |
| Request or correlation identifier | Which related events belong to the same operation? |
Audit data has its own security, privacy, and retention consequences.
Do not copy passwords, password hashes, authentication tokens, API keys, payment details, or unnecessary personal data into the audit trail. A masked value or a statement that a secret changed may be sufficient.
High-volume or unimportant fields can also bury the events people need. Define which tables and fields require old/new values, which actions need only a summary, how long the records are retained, and who may search or export them.
Users who change business data should not normally be able to rewrite its history.
Restrict direct editing and deletion of audit records. If corrections or retention cleanup are allowed, make those administrative actions controlled and traceable. Keep the audit destination, access permissions, backups, and retention policy consistent with the sensitivity of the source data.
The built-in feature covers common record changes without custom event code.
Open Security → Locking and Audit. PHPRunner can log to a database table or daily files, record login and logout activity, and enable modification or field-value logging for selected tables. Database logging makes the history available for application reports and charts.
Use the Before audit log event when a project needs to suppress an unimportant action, replace an identifier with a meaningful value, or otherwise adjust what is recorded. Keep the customization narrow so the audit policy remains easy to understand.
Start from the investigation you expect someone to perform.
Choose several important questions—such as who approved a request or how an amount changed—and verify that the proposed audit fields can answer them. Then remove data that adds risk without improving the answer.