Considerations for auditing forms


As you work with auditing forms, understand the information about different types of audit forms, audit styles, field properties, audit processing, and so on. 

View and vendor forms

When vendor or view forms have form-style auditing, the audit form created is a regular form, which includes core fields. Therefore, you might have to provide default values for the Short Description and Submitter fields because they are required fields if you have, for example, workflow configured for the audit form.

Join forms

Both form-style and log-style auditing is available for join forms. An audit of a join form is triggered if the join form contains audit fields from the base forms and the audit qualification, if present, is TRUE.

Form style

For a form-style audit, the join forms' underlying forms must also be configured for form-style audit and must be enabled. AR System creates the join forms' audit form as a join form of the underlying forms' audit forms and use the Audit Join Key fields in the join criteria, as shown in the following figure.

How a join audit form is created
JoinCreation.gif

After AR System creates the audit join form, you can modify the join criteria for the audit form to add more qualifications.

The following figure illustrates how join-form audits work in join forms. If Join Form 2 satisfies the join audit criteria, an audit occurs for Forms A, B, and C irrespective of A, B, and C's audit qualification), and audit records are visible by way of Audit Join Form 2.

If Join Form 2 fails the join audit criteria but Join Form 1 satisfies the audit criteria, an audit occurs for Forms A and B, and audit records are visible by way of Audit Join Form 1, but not Audit Join Form 2. If Form C has audit enabled, Form C is audited, and Audit Form C has entries, but audit data cannot be viewed from Audit Join Form 2.

In summary, for the first audited join form that passes the join audit criteria, AR System generates a unique GUID and uses this GUID to update the Audit Join Key fields in this join form's underlying audit forms. Because the audit join form has a join criteria based on the Audit Join Key, the audit join form displays only data entered or modified in the corresponding audited join form. If the base forms of the join are modified directly, these base forms are audited, but the audit join form does not display the modifications because the value of the Audit Join Key fields is empty.

How a join form audit-style works with joins
JoinAndAudit.gif

Log style

For a log-style audit, a regular form is created and contains the special log-style audit fields.

Important

Data entered in the join form is copied to the log form regardless of whether any of that data is pushed to the underlying base forms. The result is that the data captured in a log-style audit form might not reflect the content of the main form or its underlying base forms.

Changing field properties on the main form

When you modify the following properties of character fields on the main form, the AR System server updates the audit form:

  • Attributes
  • Field limits
  • Help text

When you modify the following properties, the audit form is unchanged:

  • Entry mode
  • Display properties
  • Index for FTS
  • Permissions

Fields on audit forms are always read-only.

Assignee Group and other dynamic group fields

For a form-style audit, if the audited form contains an Assignee Group (ID 112) field or any other dynamic group fields (IDs 60000 to 60999), the server creates these fields on the audit form. The values of these fields are always copied to the audit form, even if the Audit Option for the field is set to None.

Consider the following points when you enable a log-style audit:

  • If the audited form contains an Assignee Group field or any other dynamic group field, the server does not create these fields on the log form. 
  • If you manually add the dynamic group fields to the log form, the values of the fields are always copied to the log form, even if the Audit Option for the field is set to None.
  • When the Audit form contains dynamic group fields such as an Assignee Group field, the maximum length of the field is updated according to the maximum length of the corresponding field on the main form. Ensure that the maximum length of the field on the main form is more than the length of the field on the Audit form.  
  • When you update the maximum length of group field or any other dynamic group fields on the main form on which a log-style audit is enabled and if the corresponding field exists on the Audit form, the length of that field is automatically updated according to the field length on the main form.

DSO and audit forms

Important

The Distributed Server Option (DSO) is available only for on-premises deployments.


DSO works on audit and log forms, but the Transfer and Update flags are not updated.

Audit processing and filters

Both audit forms and main forms can have filters; however, filters cannot modify data on the audit form. For all forms that are audited (either by Form Style or by Log Style), auditing occurs at the end of Filter Phase 2. For example, if Form A has Set Fields and Push Fields filter actions and Form A has auditing enabled, the audit occurs after the Set Fields and Push Fields actions are executed.

The exception is a join form that is audited by Log Style. For these forms, auditing occurs at the end of Filter Phase 1. For example, if Join Form AB has Set Fields filter actions and has auditing enabled, the audit occurs after all the Set Field actions are executed.

If an error occurs in the transaction including errors while auditing, the entire transaction is rolled back.

Phase 3 filter actions such as Run Process, Notify, and DSO, are not audited.

For information about filter processing, see Filter-processing.

 

Tip: For faster searching, add an asterisk to the end of your partial query. Example: cert*