Loading
These are platform capabilities, so they behave the same way in every product rather than being configured separately in each.
Every write is recorded once, against the record, with the product and the person that made it. Reconstructing what happened to a customer does not mean collecting logs from six systems and hoping their clocks agreed.
Deleted records go to a recoverable state rather than disappearing, and retention is set centrally rather than per product. The specific retention periods belong in the privacy policy, which is not published yet.
Each entry records the record and field changed, the previous and new value, the person or key responsible, the product they were working in, and the automation or approval that caused it if it was not a direct edit. That last field is what makes an audit trail usable rather than merely complete — most questions are not 'what changed' but 'why'.
Access is granted and removed for the workspace rather than per product, which makes offboarding a single action with a single confirmation. The failure mode this avoids is well known: somebody leaves, six systems are cleaned up, and the seventh is remembered during an audit a year later.
Deleted records are recoverable for a period before they are removed for good, and hard deletion is itself an audited action. Retention periods and the deletion process belong in the published privacy policy — which does not exist yet, so this page states the mechanism rather than the durations.
Retention is configurable, and the default belongs in the published privacy policy rather than being stated here before that document exists.