2504 Logging And Auditing
Logging and Auditing in Tadabase
Introduction to Audit Trails
Audit trails are comprehensive records of all data changes in your application. They answer critical questions: Who changed what? When did they change it? What was the old value? Why was it changed? These records are essential for compliance, troubleshooting, and accountability.
Whether you're building a healthcare application requiring HIPAA compliance, a financial system needing audit trails, or simply want to track changes for troubleshooting, proper logging and auditing are fundamental to professional applications.
Why Logging & Auditing Matter
Audit trails serve multiple critical purposes:
Compliance & Regulation
Many industries require detailed audit trails:
- HIPAA - Healthcare applications must track all access to patient data
- SOX - Financial systems require audit trails for financial data
- GDPR - EU regulations require tracking of personal data access
- ISO 27001 - Information security standards require change tracking
- Industry Specific - Banking, government, education have specific requirements
Troubleshooting & Debugging
When data issues arise:
- Track down when incorrect value was entered
- Identify who made the change
- Understand sequence of events leading to issue
- Determine if issue is user error or system bug
- Restore correct value from history
Accountability
Create clear accountability:
- Users know their actions are tracked
- Reduces accidental or malicious changes
- Provides proof of who did what
- Supports performance reviews and training
Data Recovery
Restore previous values:
- View historical data states
- Recover from accidental deletions
- Restore record to previous version
- Understand data evolution over time
Business Intelligence
Analyze patterns:
- How frequently is data being changed?
- Which fields change most often?
- Who are the most active users?
- What times see most activity?
Types of Logging
Different types of logging serve different purposes.
1. Record Logs (Built-in)
Tadabase's native record logging automatically tracks:
- Who created the record
- When it was created
- Who last modified it
- When it was last modified
- Complete history of all changes
Available on: Professional plan and above
2. Custom Audit Logs
Create your own audit log tables for specific tracking:
- Track specific fields only
- Add custom metadata (reason for change, approval status)
- Integrate with workflow processes
- Control exactly what is logged
3. Delete Logs
Track deleted records:
- What was deleted
- Who deleted it
- When it was deleted
- Copy of record data before deletion
4. Access Logs
Track who views data:
- Record views
- Report access
- Export activity
- Login activity
5. API Logs
Track API activity:
- API calls made
- Endpoints accessed
- Success and error rates
- Performance metrics
Enabling Built-in Record Logs
Tadabase provides automatic record logging capabilities.
Activating Record Logs
To enable record logs on a table:
- Navigate to Builder > Data Tables
- Select your table
- Click Settings tab
- Find "Record Logs" section
- Toggle "Enable Record Logs" to ON
- Save settings
What Gets Logged
When record logs are enabled, Tadabase automatically tracks:
- Field Changes - Old value and new value for every field
- User Information - Who made the change
- Timestamp - Exact date and time of change
- Change Type - Create, update, or delete
- Source - Whether change was via UI, API, or scheduled task
Viewing Record Logs
Access record log history:
In Builder
- Navigate to Data Tables
- Open record you want to review
- Click "Logs" tab
- View complete change history
- See who changed what and when
In Application
Display logs to users:
- Add table component to details page
- Connect to record logs source
- Filter to show logs for current record
- Users can view change history
Log Entry Format
Each log entry shows:
Field: Customer Status
Changed By: John Smith (john@company.com)
Changed On: 2024-03-15 10:30:45 AM
Old Value: Prospect
New Value: Active
Source: Web ApplicationLog Retention
Record logs are retained:
- Indefinitely by default
- Can be exported for archival
- Can be purged via API or scheduled task if needed
- Consider storage costs for high-volume applications
Creating Custom Audit Logs
For specialized tracking requirements, build custom audit systems.
When to Use Custom Audit Logs
Custom audit logs are ideal when:
- You need to track only specific fields
- You want custom metadata (reason for change, approval)
- Built-in logs don't meet compliance requirements
- You need to integrate auditing with workflows
- You want user-friendly audit trail displays
Designing an Audit Log Table
Create dedicated audit log table:
Essential Fields
- Record Connection – Link to the record being tracked
- User Connection – Who made the change
- Timestamp – When change occurred (auto-generated)
- Action Type – Dropdown: Create, Update, Delete, View
- Field Name – Which field changed
- Old Value – Previous value (long text)
- New Value – Updated value (long text)
Optional Fields
- Reason for Change – Text explanation
- Approved By – User connection for approved changes
- Source – Dropdown: Web UI, Mobile, API, Scheduled Task
- IP Address – Network location of change
- Change Category – Dropdown: Data Update, Status Change, etc.
- Related Transaction – Connection to associated records
Implementing Custom Audit Logging
Use record rules to create audit entries.
Example: Tracking Status Changes
Track every time customer status changes:
1. Create Audit Log Table
- Customer (connection to Customers)
- Changed By (user field)
- Changed On (date/time, auto-generated)
- Field Name (text, default: "Status")
- Old Status (text)
- New Status (text)
- Reason (long text)
2. Create Record Rule on Customers Table
- Trigger: When record is updated
- Condition: Status changed
- Action: Create record in Audit Log
- Customer = Current record
- Changed By = Logged in user
- Old Status = {previous_value:status}
- New Status = {status}
3. Optional: Require Reason
- Add "Reason for Status Change" field to customer form
- Make it required when status changes
- Include reason in audit log entry
- Clear field after logging
Tracking Multiple Fields
To track changes to multiple fields:
Approach 1: Separate Rules
Create separate rule for each field:
- Rule 1: Trigger when Price changes
- Rule 2: Trigger when Stock Level changes
- Rule 3: Trigger when Status changes
- Each creates specific audit entry
Approach 2: Single Rule with Multiple Actions
One rule with multiple conditional actions:
- Trigger: When record is updated
- Action 1: If price changed, log price change
- Action 2: If stock changed, log stock change
- Action 3: If status changed, log status change
Approach 3: Generic Logging
Create generic log entry for any change:
- Trigger: When record is updated
- Action: Create log entry with "Record updated"
- Store entire record state as JSON
- Less granular but simpler
Tracking Deleted Records
Deleted records disappear, but you can preserve their information.
Approach 1: Soft Delete
Don't actually delete, just mark as deleted:
- Add "Deleted" Checkbox – Or "Status" field with "Deleted" option
- Mark Instead of Delete – Update field instead of deleting record
- Filter Out Deleted – Add filters to hide deleted records from views
- Maintain History – All history preserved since record exists
Advantages:
- Complete audit trail maintained
- Can "undelete" by unchecking
- Connection fields still work
- No data loss
Disadvantages:
- Table contains deleted records (storage)
- Must filter out deleted in all views
- Deleted data still accessible if filter missed
Approach 2: Archive Table
Move records to separate archive table before deletion:
- Create Archive Table – Identical structure to main table
- Copy Before Delete – Record rule to copy record to archive
- Add Metadata – Deleted by, deleted on, reason
- Then Delete – Delete from main table
Advantages:
- Main table stays clean
- Deleted records fully preserved
- Can restore if needed
- Better performance on main table
Disadvantages:
- Connection fields break (different table)
- More complex to implement
- Two tables to maintain
Approach 3: Deletion Log
Log details about deletion without preserving full record:
- Create Delete Log Table – Track deletion events
- Record Rule Before Delete – Create log entry with key details
- Store Critical Data – Record ID, summary, key field values
- Proceed with Delete – Delete actual record
Fields in Delete Log:
- Table Name (which table was affected)
- Record ID (original record identifier)
- Deleted By (user)
- Deleted On (timestamp)
- Record Summary (e.g., "Customer: John Smith")
- Reason for Deletion
- Full Record Data (JSON snapshot)
Implementing Pre-Delete Logging
Create record rule on table:
- Trigger: When record is deleted
- Action: Create record in Delete Log table
- Map Fields: Capture all critical information
- Note: Rule fires BEFORE deletion, so data is still accessible
Access Logging
Track who views sensitive data.
When to Log Access
Access logging is critical for:
- Healthcare records (HIPAA requirement)
- Financial data (SOX compliance)
- Personal information (GDPR requirement)
- Proprietary data
- Executive information
Implementing Access Logging
Create Access Log table:
- Record Accessed (connection)
- Accessed By (user)
- Accessed On (date/time)
- Access Type (dropdown: View, Edit, Export, Print)
- Page/Component (where access occurred)
- IP Address
- Session ID
Logging Record Views
Use page rules to log views:
- On details page, add page rule
- Trigger: When page loads
- Action: Create access log entry
- Include: Record being viewed, logged in user, timestamp
Logging Exports
Track data exports:
- Create export button with action link
- Before export action, add create log entry action
- Log: What was exported, by whom, when
- Then proceed with export
Compliance Logging
Meet regulatory requirements with comprehensive logging.
HIPAA Compliance
For healthcare applications:
Required Logging:
- All access to patient records (read, write, delete)
- Who accessed what patient data
- Date and time of access
- Purpose of access
- Location of access (IP address)
- Unsuccessful access attempts
Implementation:
- Enable built-in record logs on all patient-related tables
- Add access logging on patient detail pages
- Log all exports containing patient data
- Retain logs for minimum 6 years
- Implement log review procedures
SOX Compliance
For financial applications:
Required Logging:
- All changes to financial data
- Who approved changes
- Segregation of duties violations
- Access to sensitive financial reports
- Changes to user permissions
Implementation:
- Enable record logs on all financial tables
- Add approval workflow with audit trail
- Log changes to user roles and permissions
- Track report generation and access
- Maintain logs for 7 years
GDPR Compliance
For applications handling EU personal data:
Required Logging:
- Access to personal data
- Data exports and transfers
- Consent changes
- Data deletion requests (right to be forgotten)
- Data portability exports
Implementation:
- Log all access to personal data fields
- Track consent status changes with timestamps
- Log data export requests
- Maintain deletion request audit trail
- Enable data subjects to view their access logs
Audit Log Reporting
Create reports from audit logs.
Common Audit Reports
User Activity Report
- Show all changes made by specific user
- Group by date and action type
- Include tables accessed and records modified
Record History Report
- Complete history of changes to one record
- Timeline view of modifications
- Show old and new values
Change Summary Report
- Count of changes by time period
- Most frequently changed records
- Most active users
- Change trends over time
Compliance Audit Report
- All changes to sensitive data in date range
- Who accessed what information
- Export activity
- Failed access attempts
Building Audit Reports
Create dedicated report pages:
- Add Table Component – Display audit log records
- Add Filters – Date range, user, action type, table
- Add Sorting – Sort by timestamp descending
- Add Export – Allow export of audit data
- Add Charts – Visualize activity patterns
Scheduled Audit Reports
Automate audit report delivery:
- Create scheduled task to run monthly
- Export audit logs for previous month
- Generate summary statistics
- Email to compliance officer
- Archive report for retention
Best Practices
Follow these guidelines for effective audit logging.
What to Log
Log These Critical Events:
- All changes to sensitive data
- User authentication (login, logout, failed attempts)
- Permission changes
- Data exports
- Record deletions
- Configuration changes
- API access
Consider Logging:
- Non-sensitive field updates (if compliance requires)
- Record views (for sensitive data only)
- Search queries (for sensitive data)
- Report generation
Don't Log:
- Password values (log changes but not values)
- Sensitive data values unnecessarily
- Excessive detail that creates noise
- System-generated automated changes (unless required)
Log Data Retention
Determine retention policy:
- Compliance Requirements – Follow regulatory minimums (e.g., 7 years for SOX)
- Storage Costs – Balance completeness with storage expenses
- Access Needs – How far back do you need to search?
- Archival Strategy – Export old logs for archival storage
Log Security
Protect audit logs:
- Restrict Access – Only authorized users can view logs
- Prevent Modification – Logs should be read-only
- Log Access to Logs – Track who views audit trails
- Backup Separately – Maintain separate backup of logs
- Encrypt Sensitive Data – In logs if required
Performance Considerations
Avoid performance issues:
- Asynchronous Logging – Don't delay user actions waiting for log write
- Batch Logging – Write multiple log entries in batches
- Index Log Tables – On frequently searched fields (user, date)
- Archive Old Logs – Move old data to archive tables
- Limit Detail – Log only necessary information
Log Review Processes
Regularly review logs:
- Schedule weekly/monthly log reviews
- Look for suspicious patterns
- Investigate unusual activity
- Verify compliance with policies
- Document review findings
Practical Exercise
Build a complete audit system.
Exercise: Comprehensive Audit Trail System
Scenario: Build an audit system for a customer management application with compliance tracking.
Step 1: Enable Built-in Logs
- On Customers table, enable Record Logs
- Test by updating a customer record
- View logs tab to see change history
Step 2: Create Custom Status Log
- Create "Customer Status Log" table with fields: - Customer (connection) - Changed By (user) - Changed On (date/time, auto) - Old Status (text) - New Status (text) - Reason (long text) - Approved By (user)
- On Customers table, add record rule: - Trigger: When record updated - Condition: Status field changed - Action: Create status log entry
- Test by changing customer status
Step 3: Implement Delete Logging
- Create "Deleted Customers" archive table (same structure as Customers)
- Add "Deleted By" user field and "Deleted On" timestamp
- On Customers table, add record rule: - Trigger: When record deleted - Action: Copy all fields to Deleted Customers table
- Test by deleting a test customer
- Verify record appears in archive
Step 4: Add Access Logging
- Create "Customer Access Log" table: - Customer (connection) - Accessed By (user) - Accessed On (date/time) - Access Type (dropdown: View, Edit, Export)
- On customer details page, add page rule: - Trigger: Page loads - Action: Create access log entry (type: View)
- Test by viewing customer record
Step 5: Create Audit Reports
- Create "Audit Reports" page
- Add table showing Customer Status Log with filters: - Date range - User - Customer
- Add table showing Access Log
- Add chart showing activity by user
- Enable export on all tables
Step 6: Test Complete System
- Perform various operations: - Create customer - Update status multiple times - View customer details - Delete customer
- Check all logs are created correctly
- Generate audit report
- Export audit data
Next Steps
You now understand logging and auditing in Tadabase. You can enable built-in record logs, create custom audit trails, track deletions, log access to sensitive data, and generate compliance reports.
In the next article, you'll learn about data quality and validation—preventing duplicates, cleaning data, and implementing validation strategies to maintain high-quality data.
Next: Continue to Data Quality and Validation to learn data integrity strategies.
We'd love to hear your feedback.