Skip to main content
CYPEX Documentation
Support
v2.0.0 Latest stable release View changelog ->

History Tracking

2 min read

CYPEX may store data that requires a durable change trail. History tracking (table auditing) records every INSERT, UPDATE, DELETE, and TRUNCATE on a selected entity in cypex.t_history. Each entry holds before and after JSON images, a timestamp, the PostgreSQL role that made the change, and — when the change came through CYPEX — the CYPEX user id. Changes made directly against the table are captured too, so no separate application-level logging layer is required for those row events.

This is the primary path for data-change evidence. Related surfaces:

  • Audit — Table Audit History and User Audit Trail in the admin panel
  • Governance evidence — permission/organization decisions in cypex_log.t_permission_audit_log
  • Export & Import — optional inclusion of audit logs in application packages
  • Connector Audit — outbound connector executions in the same permission-audit stream (super admins only)

To enable it, open Builder → Database, find the table on the ER canvas, and choose Auditing from its three-dot menu:

History Tracking

The dialog explains what is captured and warns that auditing costs write performance. Confirm with Enable:

Auditing

CYPEX then deploys two changelog triggers on the table — one statement-level trigger for TRUNCATE and one row-level trigger for INSERT, UPDATE, and DELETE — which store the changes as JSON. Auditing is not available on foreign tables (FDW).

Recorded changes are readable in Monitor & Audit → Table Audit History by super admins and organization admins:

Audit Tables

Clicking “Details” on any entry shows exactly what changed, field by field:

Audit Details

Disabling auditing removes the triggers but keeps the history already recorded. CYPEX never deletes audit data on its own and runs no retention job: cleanup is the administrator’s responsibility, so that what is deleted, when, and how stays an explicit decision.

See also