Configuring Tables and Columns for Audit This document details how to enable or disable auditing of tables/columns using predefined attributes, namely audit_type (Table level), no_audit (Column level) and audit (Column level). 1. Available pre-defined attributes for configuring audit The explanation given in this document is relevant only for the tables enabled for Auditing – audit flag set to true in sys_dictionary. 1.1. Table level attribute for configuring auditing of columns: audit_type 1.2. Column level attributes available to exclude and include columns from auditing: no_auditaudit 2. Using table level and field level attributes The attribute audit_type is set at the table level. Based upon the audit type selected in the attribute, the audit or no_audit column attributes will be used for auditing determination. 1. If audit_type is not set or audit_type=blacklist, then the code looks for columns to be blocked from auditing. If the no_audit attribute is not added for a column, then it means that the column will be audited. 2. If audit_type=whitelist, then the code looks for columns to be audited. Columns with the audit attribute will be included in the audit. If the audit attribute is not specified, then the column will not be audited. Further information on the inclusion or exclusion of column auditing can be found in: KB0723730 – Auditing Exclusion List, KB0724176 – Auditing Inclusion List 3. Audit Configuration Digest Audit Column for Type Collection on the table Set to true 3.1. Exclusion list Auditing Table where majority of the columns are to be audited Table Level audit_type=blacklist or <do not set the attribute> Columns not to be not audited no_audit Columns to be audited <no attribute to be set> 3.2. Inclusion list Auditing Table where majority of the columns are not to be audited Table Level audit_type=whitelist Columns not to be not audited <no attribute to be set> Columns to be audited audit 3.3. Examples 3.3.1. Exclusion list Auditing Table and Attribute incident_fact_table (audit_type=blacklist or unspecified) Column and Attribute status assigned_to (no_audit) category priority location (no_audit) Is Audited? YES NO YES YES NO 3.3.2 Inclusion list Auditing Table and Attribute incident_fact_table (audit_type=whitelist) Column and Attribute status assigned_to (audit) category priority location(audit) Is Audited? NO YES NO NO YES 4. Default OOB (Out of Box) Behavior If the “Audit” value against the table is set to true, then the auditing mechanism defaults to blacklist. This means that all the columns in the table will get audited. 5. FAQs (Frequently Asked Questions) Q1. I have a table which has 10 columns out of which only 2 are to be audited. What is the best practice? A1. You should use Inclusion List Auditing. See Section 3.2 for the same. Q2. I have a table which has 10 columns out of which 2 are not to be audited. What is the best practice? A2. You should use Exclusion List Auditing. See Section 3.1 for the same. Q3. I am introducing a new table. Should that be audited? A3. Auditing helps in compliance purposes and in some cases to debug problems. If this is a table that has Activity Stream that indicates old value and new value, then it is better to audit the table. Any table that is used by the customer for daily transactional purposes may also be audited to know who has done what. Tables used by development teams for bookkeeping purposes, that are not customer-facing, need not be audited. Q4. What kind of columns is preferred to be audited? A4. Columns containing crucial information to track who/what/when modified the values alone are to be audited. A trivial example could be columns like Priority, status, assigned_to have to be audited as the change in value is important for the customer. Columns used for internal processing and not customer facing need not be audited. Example: some tables have ip_address columns to be audited. In a typical cloud set up, IP addresses are ephemeral and do not really add value. Another example could be a case where an internal job must update a few columns and maintain a checkpoint status or last_synchronized kind of information. Such columns need not be audited. This is more of a general guideline and the right answer is “always depends on the customer use-case.” Q5. I want none of the fields on my table to be audited. How do I achieve that? A5. Ensure that Audit is set to false against your table in System Dictionary (Type = Collection). No attribute setting is required. Q6. I want all the fields of my table to be audited. How do I achieve that? A6. Ensure that Audit is set to true against your table in System Dictionary (Type = Collection). No attribute setting is required. Despite the audit setting of the fields in Sys Dictionary, all the fields will get audited.