Entity Change Tracking

The admissions system maintains a detailed audit trail of changes to entities. When a record is modified, the system captures before and after values for every changed field, creating a diff-style history that shows exactly what changed, when, and by whom.

How Change Tracking Works

When a user modifies a lead, form, pipeline, stage, or other entity:

1. The system captures the current state of the record (before values).
2. The changes are applied.
3. The system captures the new state of the record (after values).
4. A change payload is stored in the audit log, containing both states.

This creates an immutable record of every modification.

Viewing Change History

From the Audit Log

1. Navigate to Configuration > Audit Log.
2. Find an "updated" action in the log.
3. Click the row to expand the change details.
4. The detail view shows a before/after diff of all changed fields.

From an Entity

1. On a lead, form, or other entity's detail page, find the activity timeline or history section.
2. Click on a change entry to see what was modified.

Change Payload Format

Each change entry records:

Component	Description
Entity Type	What type of record was changed (Lead, Form, Stage, etc.)
Entity ID	The unique identifier of the changed record
Action	The type of change (created, updated, deleted)
User	Who made the change
Timestamp	When the change occurred
Before Values	The field values before the change
After Values	The field values after the change

Example Change Diff

For a lead status change:

Field: status
  Before: "New"
  After: "Contacted"

Field: updated_by
  Before: "John Smith"
  After: "Jane Doe"

What Is Tracked

Lead Changes

• Name, email, phone updates
• Status changes
• Stage transitions
• Priority changes
• Owner/assignment changes
• CRM field updates
• Notes added or modified

Form Changes

• Form name and settings updates
• Published/unpublished status changes
• Schema modifications

Pipeline & Stage Changes

• Pipeline name, status, and default flag changes
• Stage name, order, and color changes
• Stage additions and removals

Configuration Changes

• Program updates (name, code, active status)
• Fee changes (amount, currency)
• Email template modifications
• Enrolment year updates

Non-Diff Change Payloads

Some audit entries capture changes in a simpler format without a full before/after diff:

• Stage transitions -- Records from_stage and to_stage names as flat fields.
• Bulk operations -- Records the action type and affected record count.
• System events -- Records event descriptions without field-level diffs.

The audit log display handles both formats gracefully, showing field-level diffs when available and descriptive text for other change types.

Data Retention

Audit trail data is stored indefinitely by default:

• Change records are part of the audit log table in the database.
• Historical entries are not automatically purged.
• Export the audit log periodically if you need to archive historical data externally.

Using the Audit Trail

Investigating Issues

When a record appears incorrect:

1. Open the audit log.
2. Filter by the entity type and search for the record name.
3. Review the change history chronologically.
4. Identify when the incorrect change was made and by whom.

Compliance Reporting

For data protection audits:

1. Export the audit log for a date range.
2. Filter by entity type to focus on the relevant records.
3. The before/after diffs provide evidence of data handling practices.

Reverting Changes

While the system does not have an automatic "undo" feature, the audit trail tells you:

• What the previous value was.
• When it was changed.
• Who changed it.

Armed with this information, a user can manually restore the previous value.

TIP

The audit trail is your safety net for data integrity. When something goes wrong, it provides the complete history needed to understand and correct the issue.

Was this helpful?