Understanding audit trail | Zoho Creator Help

Understanding audit trail

In a nutshell
The Audit Trail feature in Zoho Creator keeps track of the changes made to your application's data, which includes both user and system-generated activities. It records what was modified, when, how, and by whom, while also capturing actions triggered through Deluge scripts, APIs, workflows, and form emails. This serves as documentary evidence for the sequence of activities in your application records to ensure detailed activity monitoring.
Availability
  1. Audit trail is available in both free and paid pricing plans of Creator.
  2. For free plans, the audit data for both Change Audits and Data Transfer Audits is retained for three months. For paid plans, Change Audit data is retained for three years, while Data Transfer Audit data is retained for three months. Refer section 2 to know more about the tabs in Audit Trail.
  3. Only the super admin and admins can access and manage the audit trail for all the applications in a Creator account.

1. Overview

A typical organization has several users accessing its applications and services. Monitoring every user's activity is crucial to prevent potential threats to sensitive data and prevent data misuse. The Audit Trail feature in Zoho Creator helps organizations maintain a detailed log of all activities performed within the application's live mode. It plays a crucial role in identifying changes to app data and tracking the sequence of actions in the event of security violations.
You can customize what you review by setting filters based on specific dates, user types and actions performed, record IDs, and email addresses of users. For example, while investigating a security incident, the Audit Trail feature helps detect who exported sensitive data or deleted critical records and when those actions were performed.
Audit Trail is available in two types, based on the level of detail captured:
  1. Basic Audit Trail captures actions performed directly by users in the live mode of the application, such as record creation, updates, deletions, and report activities like import, export, and print.
  2. Advanced Audit Trail extends this capability by capturing system-driven actions, including those triggered through Deluge script executions, API calls, and form emails, providing deeper visibility into background operations.
Activities performed in live mode are captured through the following sources.
  1. User actions - Direct actions performed by users within the application, such as creating, editing, or deleting records as well as importing, exporting, and printing reports.
  2. Deluge - Actions triggered through custom Deluge scripts, including updates and task executions.
  3. Form email data - Data interactions initiated via form-based emails, such as submissions or updates triggered through email inputs.
  4. APIs - Data changes or retrievals made through external API calls, ensuring transparency in third-party system interactions.
  5. Workflows - Automated actions performed by configured workflows, including task executions, record updates, and conditional operations.

1.1. See how it works


1.2. Use cases

Case 1: Tracking major data updates in an employee application
Let's assume you've created an Employee Management application for your organization. As an HR administrator, you need visibility into all updates made to employee records, from onboarding and role changes to payroll adjustments and access to confidential reports. With the Audit Trail feature, every action taken on an employee profile is automatically logged. For instance, if a manager updates an employee’s salary or modifies their role, the system logs the following details:
  1. Who made the change
  2. What type of action was taken (create, edit, delete, view, etc.)
  3. Before and after values for critical fields (e.g., salary, designation)
  4. When the change occurred
  5. How the action was performed (user action, API, workflow, etc.)
This level of detail ensures that all changes are traceable, reducing the risk of sensitive updates and enabling HR to confidently respond to employee disputes or compliance checks with labor laws and internal policies.

Case 2: Tracking sensitive data updates in a healthcare application
Let's assume you've created a Hospital Care application for your clinic. This app enables patients to view lab results, schedule appointments, and update their personal information (includes PII and EPHI data), making user-activity tracking essential. The Audit Trail automatically logs every interaction, including:
  1. Patient-side actions: appointment scheduling and modifications, record views or downloads.
  2. Staff-side actions: access to patient records, edits to medical history, prescription updates, or responses to patient messages in record comments
For each event, the following is captured and can be viewed in the Audit Trail page:
  1. Who performed the action (patient or staff username)
  2. What was done (viewed lab results, edited personal info)
  3. When it happened (timestamp)
  4. Where the action originated (IP address)
This detailed log provides visibility into all essential activity, helping healthcare organizations respond to access concerns, security breaches, or compliance audits.

1.3. Navigation guide

In the Operations section under MANAGE module of your account, choose Audit Trail. On the Audit Trail screen, click View Audit Trail in the center, select the required application and form, and choose the respective tabs to view the required audit data. Learn how
<video>

2. What are the different tabs in Audit Trail?

The audit trail data is categorized into the following two tabs.

2.1 Change Audits

This tab captures user actions in records like create, edit, delete, and restore, while also logging before-and-after edit values for compliance purposes. These user actions are logged from the app’s live mode, along with Deluge script executions, API calls, form emails, and data access actions in workflows. In this tab, you can view who performed the action (created, edited, deleted or restored) on the record (users' email address), the timestamp at which they performed it, and the respective record ID.



Info
You can restore the record changes. Learn how
You can click on an entry to view its detailed log that provides full visibility into the record details and the device type on which the record changes were performed. Each Detailed Log has the following two sections apart from displaying the user details and the component type in which the user performed that action.


  1. Overview: App and component names along with the component type, and source of the action. 
  2. Record Details: Field name, type, value, and attachments (names of uploaded images and files) for edited,deleted, and restored records. If a record is edited, the before-and-after edit values will also be displayed.

  3. Subform Details: This section appears when your form has a subform in which a user has performed the following actions. The record ID of the subform will also be captured.
    1. Created: Captured when a subform row has been added.
    2. Edited: Captured when a subform row has been edited, with the before and after edit values.
    3. Deleted: Indicates that a subform row is deleted.
  4. Comment Details: Details of the created and deleted comments (available only for record comment-related actions).
Notes
Note: You can also switch applications and see the record edit history of a different app's components. 

2.2 Data Transfer Audits

This tab captures export, print, and import activities on reports by users, offering a comprehensive log of these actions for oversight.



Here, you can view who performed the action (import, export, or print) on the record (users' email address), the timestamp at which they performed it, and the respective record ID. You can click on an entry to view its detailed log that provides full visibility into the record details and the device type on which the record changes were done. Each Detailed Log has the following two sections apart from displaying the user details and the component type viewed.


  1. Overview: App and component names along with the component type, source, and the record count.
  2. Details: Report name, number of records, PII fields (if any), file format and size.
Info
In the detailed view of export and print activities, details of any applied filters in the report and name of the file attachment that has been exported will be captured.

3. Audit Reports

An audit report is a downloadable report generated from audit trail data based on user-selected filters. It enables super admins and admins to review detailed audit data, ensuring transparency, traceability, and compliance across applications.

3.1 How to generate an audit report

Reports can be generated based on the selected audit tab and filter criteria. To generate an audit report, apply the required filters in the respective audit tab  and click the Generate Report button at the bottom-right corner.



Once initiated, the report generation progress can be tracked in the Audit Reports tab. Here, you can view other details that include application name, component type, generated by, generated date, export status, and expiry date. You can also download the completed reports from here.



4. Setting audit preferences

You can set audit preferences to control the type and level of actions captured in your application. By default, the audit trail captures user activities performed in the live mode of the app under Basic audit trail. You can further extend this to capture more detailed system-level actions under Advanced audit trail, including actions triggered through Deluge scripts across apps, API calls, form emails, and data access actions in workflows.


Info
These preferences can be configured for audit data only in the Change Audits tab and isn’t applicable to Data Transfer Audits.

4.1 How to capture IP address

The Capture IP Address toggle allows you to record the IP address associated with each action in the audit trail. When enabled, every activity, such as record creation, updates, access, or data transactions will include the originating IP address as part of the audit trail. This additional information provides better visibility into where actions are performed from, helping administrators enhance security monitoring, detect suspicious activity, and support compliance requirements. 
Info
By default, the option to capture IP Address will be disabled. 

4.2 Admin activity

This tab captures administrative-level actions performed on existing audit trail configurations. Unlike regular audit trail, which focus on end user activity, admin activity focus on who within the organization - super admin, admins, or app admins, changed audit settings, applied filters, or altered the way auditing works. Admins can also export this as a .csv file for compliance reviews or internal reporting. To know more on how to view captured activity by admins, refer this section.

5. Applying filters

Notes
Note: The selected filter will be applied to the tab that you're currently viewing the audit trail for.
Filters enable you to be precise about the parameters with which the audit trail data must be filtered. You can filter by:
  1. Date Range: View audit data from by defining a custom date range.
  2. Specific Date: Select a specific date to view audit data
  3. User Type: Narrow results by User, Portal user, or Public user.
  4. Actions:
    1. Change Audits - Focusses on specific activities such as Created, Edited, Deleted, and Restored for records, and Created and Deleted for record comments.
    2. Data Transfer Audits - Focusses on activities like Exported, Imported, and Printed reports. Here, you can choose the component - All reports or the required report to view the audit data.
  5. Record ID: Search for audits related to a particular record by entering its ID.
  6. Source: Choose the source of the action, such as User actions, Deluge scripts, API calls, form emails  or select All to include all sources.
  7. User Email Address: Filter results based on the email address of the user who performed the action.

6. Billing and usage

The Billing page displays a comprehensive inventory that lists details of your current Creator subscription. Here, you can view the storage consumed by audit trail, measured in GB. Learn more
Notes
Note: In billing, the audit trail storage is calculated based only on Change Audits data. 

7. Points to note

  1. The Audit Trail feature is application-specific and lets you view the history of the action types performed in your application categorized by two tabs.
  2. By default, the Basic audit trail actions will be captured. API-related audit actions, which were previously included in the Basic audit trail, are now available under the Advanced audit trail. You can choose to capture Advanced audit trail actions by ticking the checkboxes beside the required applications.
  3. Export and print actions from pivot reports (pivot charts and pivot tables) will not be captured in audit trail.
  4. While generating audit report after applying filters,
    1. Each export file can include data from a maximum duration of 6 months or up to 1 GB in size, whichever limit is reached first.
    2. The generated audit reports will remain available for download for 7 days from the date of generation.
    3. Admins can generate export of multiple audit reports, but only one export will be processed at a time.
  5. The maximum size allowed per audit entry is 512 KB. Once this limit is exceeded, only the field names are captured in the detailed log, while the corresponding field data is omitted.
Change Audits:
  1. Only record IDs will be captured in the detailed log for created or duplicated records.
  2. When records are deleted through user actions or API, the audit trail captures all field values, record comments, and associated record details. However, for records deleted via delete records Deluge task, only the Record ID is audited.
  3. Restore record:
    1. Only field values are restored; record comments are not restored.
    2. Only records deleted within the last three days are eligible for restoration.
    3. Record restoration may fail if the associated form or its fields have undergone metadata changes after deletion. his includes adding, removing, renaming, or modifying fields, changing field types or relationships, or making other structural changes to the form. In such cases, the deleted record may no longer be compatible with the current form structure, preventing successful restoration.
    4. Restoration of a main form record will fail if its linked subform records have been deleted.
    5. Restore functionality is not supported for audit entries created before the feature release date i.e., Sep 29, 2026.
  4. Bulk actions:
    1. For bulk edit, duplicate, and delete actions performed by users or via APIs, a separate audit entry is created for each record in the bulk action performed.
    2. Records added via import are captured under a single audit entry containing all imported record IDs.
    3. For records updated through import, a separate audit entry is generated for each modified record.

8. Best practices 

  1. Regularly download audit reports for long-term compliance storage.
  2. Use filters to narrow down reports to specific incidents or users.
  3. Share reports with your compliance team or auditors as part of periodic reviews.
  1. View and manage audit trail
Previous
What's next
Previous
Before proceeding, learn how to manage various functions for the Solutions and their components efficiently from one place by checking out the Understanding Operations page.
What's next
Learn how to view, filter, and manage audit data for better tracking and analysis of application activities.