Building Audit Trails in Knack

What You'll Learn

This article explains how to build audit trails in your Knack app. HIPAA requires you to track who accessed PHI and what changes were made. Knack provides several tools to help you do this, and this article covers how to use them together.

Why Audit Trails Matter for HIPAA

HIPAA's Security Rule requires covered entities to implement audit controls that record and examine activity in systems containing ePHI. In practice, this means you need to be able to answer questions like:

• Who created this patient record?
• When was it last modified?
• What changed?
• Who made the change?

If you can't answer these questions, you have a gap in your compliance. Audit trails provide the documentation you need for internal reviews, compliance audits, and investigating potential breaches.

Record History

Knack's built-in record history feature logs changes made to individual records. When enabled, you can view a timeline of edits for any record directly in the Builder.

Record history tracks:

• What fields were changed
• The previous and new values
• When the change was made
• Who made the change (if the change was made by a logged-in user)

How to enable it: Go to Settings > General, scroll down to Record History, and toggle it on.

⚠️

Record history data is retained for 3 months. After 3 months, the history for a given change is no longer available. If your compliance program requires longer retention, you'll need to build a change log or version history table to capture changes permanently.

System Fields

Every table in Knack includes system fields that automatically capture metadata about each record. These fields are useful for building audit-friendly elements in your app.

Key system fields for audit trails:

• Date Created — the date and time the record was first created
• Date Modified — the date and time the record was last updated
• Record ID — the unique identifier for the record

System fields are available by default but may be hidden. You can show them in your table settings and include them in elements on your pages.

For HIPAA apps, consider adding Date Created and Date Modified columns to any table element that displays PHI. This gives users and admins visibility into when records were last touched.

For details on managing system fields, see System Fields.

Tracking Who Made Changes

System fields track when a record was created or modified, but they don't track who made the change. To capture this, you have three options depending on how much detail you need:

Add a "Last Modified By" field. The simplest approach. Add a connection field to your table and use a record action on your forms to stamp the logged-in user on each edit. This only tracks the most recent user, not a full history. See Tracking Record Changes for a step-by-step guide.

Build a change log. Create a Logs table that records who made a change, when, and what type of action was taken (created, updated, etc.). This gives you a permanent log but doesn't capture what specific field values changed. See Creating a Change Log for Records.

Build a version history. Create a Logs table with fields that match your source table. Record actions copy the current field values into a new log entry on every create and edit. This gives you a full before-and-after trail. See Creating a Version History for Records.

Choosing the Right Approach

For HIPAA apps, a change log or version history is recommended. Record history is useful for quick lookups in the Builder, but it's not a long-term compliance solution.

📘

Start with a change log if you're unsure. It's simpler to set up and covers the basics (who and when). You can upgrade to a full version history later if you need to track specific field values.

What to Track

At minimum, your audit trail should capture:

• Who — the user who performed the action
• What — the type of action (created, updated, deleted, viewed)
• When — the date and time of the action
• Which record — a connection to the record that was affected

For HIPAA apps, also consider tracking:

• Comments or notes — optional context about why a change was made
• The specific fields that changed — use a version history table to capture field values at each point in time

Next Steps

• Tracking Record Changes — The simplest approach using system fields and a "Last Modified By" connection
• Create a Change Log for Records — Track who made changes and when
• Create a Version History for Records — Track the actual field values that changed