Audit Rules

\# audit rules and logs on records written by oleksandr melnyk | last published at october 01, 2025 \# # audit rules \# overview audit rules provide comprehensive tracking and monitoring capabilities for your system this functionality enables you to monitor changes made to critical business data, maintain compliance requirements, and review historical modifications the audit trail functionality automatically records who made changes, when they were made, and what values were modified, creating a complete history of data changes across your organisation the audit trail functionality helps organisations maintain accountability, meet regulatory compliance requirements, and investigate data discrepancies by providing a detailed log of all system activities on selected objects \# functional end user guide \# viewing audit logs required access users need appropriate group permissions to view audit logs the visibility of audit logs depends on the security groups configured for each audit rule \# accessing logs for a record when an audit rule is active for a particular object, you can view its change history directly from the record open any record that has audit tracking enabled look for the "view log" action in the sidebar or action menu click "view log" to see the complete history of changes for that record \# understanding the log view the log view displays the following information for each change log id unique identifier for the log entry action type of operation performed (create, write, delete, or mass editing) date when the change occurred user who made the change table name the database object affected transaction id the specific record that was modified old value text previous values before the change new value text new values after the change \# searching audit logs to search for specific changes in the audit logs navigate to knowledge >> reporting >> audit >> logged actions use the search bar to filter logs by field name (e g , enter "state" to find all state changes) field name and value (e g , "state"=>"done" to find records changed to done state) specific value (e g , enter "done" to find all occurrences of this value) you can also search for deleted child logs using the special filter option when available search tips use quotation marks for exact field names "field name" use "=>" or " " to search for specific field value pairs multiple search formats are supported for flexibility \# opening original records from logs for existing records (not deleted), you can open the original record directly from the log open the specific log entry in form view click the "open transaction" button the system will open the original record in a pop up window \# understanding child logs when viewing logs for a parent record, you can also see changes to related child records (such as order lines on a sales order) this provides a complete audit trail of all related changes in one view \# setup and configuration guide (for administrators/superusers) \# creating audit rules required access knowledge→manager or configuration→configuration access rights are required to create and manage audit rules important note subscribing or unsubscribing to audit rules during peak hours may overload the system please make changes during low traffic times to avoid disruptions \# setting up a new audit rule navigate to knowledge >> reporting >> audit >> audit rules click "create" to add a new rule configure the following settings \# basic configuration rule name enter a descriptive name for the audit rule object select the erp object/model you want to audit (e g , sales order, invoice, product) actions to log select which operations to track log creates track when new records are created (enabled by default) log writes track when records are modified (enabled by default) log deletes track when records are deleted (enabled by default) allow adding child lines enable to allow subscription of child models without requiring separate audit rules auto removal interval number of months after which logs will be automatically removed (default 12 months, minimum 3 months, set to 0 to disable auto removal) \# fields to log tab by default, all fields are logged to log only specific fields click the "fields to log" tab add the specific fields you want to track only changes to these selected fields will be recorded in the audit log note if no fields are specified, all field changes will be logged \# security tab control who can see the "view log" action click the "security" tab select the user groups that should have access to view logs for this object if no groups are selected, the view log action will be visible to all users \# child logs tab configure logging for related child records click the "child logs" tab select one to many fields representing child relationships you want to include in the audit trail when viewing logs, changes to these child records will be included note if "allow adding child lines" is not enabled, the system will require that audit rules exist for the child models as well \# activating an audit rule after configuring all settings, click the "subscribe" button the rule status will change from "draft" to "subscribed" the system will begin logging changes immediately a "view log" action will be added to the relevant object's sidebar warning only subscribe audit rules during off peak hours to avoid system performance issues \# deactivating an audit rule open the subscribed audit rule click the "unsubscribe" button the rule will return to "draft" status no new logs will be created, but existing logs remain accessible \# managing existing audit rules \# viewing all audit rules navigate to knowledge >> reporting >> audit >> audit rules to see all configured rules the list view shows rule name object being audited which actions are being logged current status (draft or subscribed) rules in blue are in draft status, while black indicates subscribed (active) rules \# filtering audit rules use the search filters to find specific rules draft show only inactive rules subscribed show only active rules search by rule name or object name \# best practices for administrators \# performance considerations only audit critical business objects to minimise database overhead consider logging specific fields rather than all fields for high volume objects set appropriate auto removal intervals to manage database size always subscribe/unsubscribe rules during low traffic periods \# compliance and retention review regulatory requirements for data retention in your industry set auto removal intervals according to compliance requirements consider longer retention for financial and critical business objects document your audit rule configuration for compliance audits \# security recommendations restrict audit rule management to trusted users only use security groups to control who can view sensitive audit logs regularly review audit rules to ensure they align with security policies monitor the logged actions for any suspicious activities \# troubleshooting common issues \# view log action not appearing if the view log action doesn't appear for a record verify the audit rule is in "subscribed" status check that your user account belongs to the security groups configured for the rule ensure the object has an active audit rule configured \# logs not being created if changes aren't being logged confirm the audit rule is subscribed verify the specific action type (create/write/delete) is enabled in the rule check if specific fields are configured and whether your changes affect those fields \# performance issues after enabling audit rules if system performance degrades review the number of active audit rules consider logging specific fields instead of all fields evaluate the auto removal interval settings schedule subscription changes for off peak hours