From the Logs area (Admin > Logs), you can view a history of actions within your Vault. There are multiple pages in this area, each of which displays the history for a distinct type of action.

How to Export Audit Logs

To export audit logs:

  1. Open the page for the data you wish to export (system, document, etc.).
  2. Set a date range using the Quick history drop-down. You can also choose a range by entering dates and clicking Get History. If you are viewing Document Audit History, there are different filter options. See below.
  3. Click on the Actions menu (represented by a gear icon) and choose CSV, Text, or PDF. If the Enable multilingual document handling option is set, only the TXT and PDF options will be available.

CSV Exports

The exported CSV file shows information in a slightly different format. For example, the CSV file separates the details of each event into individual columns.

CSV Export

PDF Exports

When you export as PDF, Vault adds page numbers and a cover page to the PDF. Admins with the correct access can modify the cover page template. All audit histories and audit trails use the same Audit Export Cover Page template.

About Export Limits

Vault includes limits on how many days of results you can view and export in a single request. If you need to export a longer history, you can export multiple times, changing the date filter each time.

  • System Audit History: Up to 31 days of results
  • Login Audit History: No limit
  • Document Audit History: No limit
  • Domain Audit History: Up to 14 days (two weeks) of results
  • Object Record Audit History: No limit
  • Debug Log: Up to 30 days of results per log
  • Runtime Log: Up to 1 day of results at a time, with a maximum of 30 days in the past
  • API Usage Logs: Up to 1 day of results at a time, with a maximum of 30 days in the past

System Audit History

The System Audit History page displays Vault-level configuration and settings changes, for example, updates to document types, workflows, or object configurations. This page also displays Vault Loader actions. For each event, you can see the timestamp, the user making the change, affected item, and description. Note that when users reorder certain components, such as document lifecycle states or user actions, Vault doesn’t capture these changes in the System Audit History.

System Audit History

Login Audit History

The Login Audit History page displays user authentication events, including users’ logins, failed login attempts, and password changes. For each event, you can see the timestamp, user’s login name, originating IP address, type of event, user’s browser, user’s platform, and Vault ID.

Login Audit History

Login Types

Users exist at the domain level and a user login occurs at the domain level. Login Audit History shows Vault-level authentication events each time a user accesses the current Vault. In some situations, it also shows the domain-level authentication.

The Type field tells you which kind of event occurred:

  • Enterprise Home Authentication identifies a domain-level login event. If there is no additional Vault Authentication event, this user did not access the current Vault.
  • Vault Authentication appears when a user accessed the current Vault, after logging into another Vault or logging into My Vaults.
  • User Login means that a user logged in directly to the current Vault. This type also appears for unsuccessful logins (wrong passwords, etc.).
  • SSO Login indicates that a user logged in using a Single Sign-on security policy.
  • OAuth Login displays the name of the OAuth/OpenID Connect profile.
  • Delegate Access indicates when a delegate user logged into the delegated Vault. Vault displays the user name as: {delegate} on behalf of {delegator}.

Last Login Information

The easiest way to find the last login date and time for a specific user is from Admin > Users & Groups > Users.

Vault Context for Multi-Vault Domains

Vault user accounts and logins occur at the domain level, which means Admins in multi-Vault domains need to know the specific Vaults where a user logged in. To see the Vault ID for individual login events, view or download the Login Audit History.

Vault ID will appear for the following login event types:

  • Vault Authentication
  • User Login
  • Enterprise Home Login
  • SAML Authentication
  • OAuth 2.0/OpenId Connection Authentication

Vault ID is only logged for Vault-specific events. For domain-level events, the audit logs will not populate Vault ID. For example, when a user who has not been assigned to any Vaults logs in, that audit entry will not include a Vault ID.

Document Audit History

The Document Audit History page displays document-related events, including views, send as link actions, task completions, and modifications to document fields. For each event, you can see the timestamp, user’s login name, affected item, and description.

See the complete list of audited actions. Document Audit History includes audit entries for deleted documents, including entries for each document deletion.

Filtering Document Audit History

At the top of the page, you will see that by default, the audit log is already filtered by Timestamp, in the last day. You can select a different time frame from the second drop-down.

To change or add filters for the document audit history:

  1. Select Timestamp, Event, or User from the drop-down.
  2. Optional: If you selected Timestamp, select a date rage in the drop-down to the right. If you selected in the range, two additional date fields will appear. Click on each field to select a start and end date for the range.
  3. Optional: If you selected Event, the operator In and a second drop-down will appear. Select the desired event(s) from the second drop-down. Click Apply.
  4. Optional: If you selected User, the operator Equals and a second drop-down will appear. Select the desired user(s) from the second drop-down. You can select multiple individual users, but not user groups.
  5. Optional: Click on the blue Add filter button to add any of the remaining filters (Timestamp, Event, or User).
  6. Click Apply to update the table.

Filtering Document Audit History

About OAuth / OpenId Connect Authentication Event Logging

When starting and stopping OAuth 2.0 / OpenID Connect event logs, Vault stores the following detailed logging information in the Domain Audit History:

  • Timestamp: The time when the event occurred
  • User ID: The user ID of the admin who initiated or ended the the capture. When the capture is stopped after 10 requests, Vault sets the value to System.
  • User Name: The user name of the admin who initiated or ended the capture. When the capture is stopped after 10 requests, Vault sets the value to System.
  • Type: Vault sets the event type to OAuthSetting
  • Item: The OAuth/OpenID Connect profile name.
  • Action: Vault sets to Edit
  • Filed Name: Vault sets to captureAuthenticationEvents

Object Record Audit History

The Object Record Audit History page displays all changes to object records. For each event, you can see the timestamp, user’s login name, affected item, and description. Note that Vault only captures changes to object records when the Audit data changes setting is enabled on that object.

Vault does not audit individual field values for newly created records. For example, the audit trail for a new Product record would only include a single entry, and the Event Description would be “Product: CholeCap created.” We recommend exporting the current record along with the audit trail to ensure a complete export of all values. When a user deletes an object record, the audit trail captures all field values.

At the top of the page, you will see that by default, the audit log is already filtered by Timestamp, in the last day. You can select a different time frame from the second drop-down.

To change or add filters for the object record audit history:

  1. Select Timestamp, Event, User, or Object from the drop-down.
  2. Optional: If you selected Timestamp, select a date rage in the drop-down to the right. If you selected in the range, two additional date fields will appear. Click on each field to select a start and end date for the range.
  3. Optional: If you selected Event, the operator In and a second drop-down will appear. Select the desired event(s) from the second drop-down. Click Apply.
  4. Optional: If you selected User, the operator In and a second drop-down will appear. Select the desired user(s) from the second drop-down. You can select multiple individual users, but not user groups.
  5. Optional: If you selected Object, the operator In and a second drop-down will appear. Select the desired object(s) from the second drop-down.
  6. Optional: Click on the blue Add filter button to add any of the remaining filters (Timestamp, Event, User, or Object). You can define up to three (3) filters in any combination.
  7. Click Apply to update the table.

Object Record Audit History

Domain Audit History

The Domain Audit History page displays changes that occur at the domain level, including updates to user details, security policies, and network access rules. For each event, you can see the timestamp, user making the change, affected item, and description. Note that the Domain Audit History events are the same when viewed from any Vault in the domain.

Domain Audit History

Vault Java SDK Logs

The Vault Java SDK Logs capture details related to your custom Vault Java SDK integrations. Learn more about the Vault Java SDK on the Developer Portal.

Debug Log

The Debug Log captures details about Vault Java SDK errors, which may be errors in your custom code or errors from exceeding time, memory, or size limits. Debug logs are not enabled by default, and must be enabled per user. Once enabled for a user, every request initiated by that user generates a log file.

By default, the Vault Owner and System Admin security profiles have permission to view the Debug Log and set up log sessions for a particular user. To create a debug log for a user, navigate to Admin > Logs > Vault Java SDK Logs and click Create. Each Vault can have up to 20 users with enabled debug logs.

Debug logs expire after 30 days. At the end of 30 days, Vault deletes the debug log and all log files. The Days to Expiration column displays the number of days remaining until expiration. On a specific debug log, the Reset Log button deletes all existing log files and resets the expiration date to 30 days.

Debug logs have the following limits:

  • Maximum number of users per vault for which logging can be enabled: 20.
  • Maximum log size: 10MB. When the limit is reached, logging immediately terminates, even if the request is incomplete.
  • Maximum number of log files: 20. Once the limit is reached, logging stops.
  • Logs are available for 30 days from the day a log is created for a user. At the end of 30 days, the debug log and all log files are deleted.

This log is not always on by default. If you experience issues related to Vault Java SDK, a Vault Owner or System Admin should create a debug log session to assist with troubleshooting. Learn more about how to use and customize the Debug Log on the Developer Portal.

Runtime Log

The Runtime Log captures additional logging for Vault Java SDK transactions. Unlike the Debug Log, which is enabled per user, the Runtime Log is enabled per Vault.

The Runtime Log is enabled by default and captures runtime exceptions. To disable logging or capture additional data, Vault Admins with the General Information: Edit permission can adjust options from the Settings > General Settings page. Adjusting log-level settings to capture additional data may decrease Vault performance. Changing these settings only affects new log entries.

Log-level settings for the Runtime Log include the following options:

  • DISABLED: The runtime logs are off. No logs are created.
  • EXCEPTIONS: The runtime logs capture runtime exceptions only. This is the default setting and does not have performance implications.
  • ERROR: Runtime exceptions and errors. Generally, errors block transactions from proceeding.
  • WARN: Runtime exceptions, errors, and warnings. Generally, warnings indicate a potential issue but do not block transactions from proceeding.
  • INFO: Runtime exceptions, errors, warnings, and information. Generally, informational messages do not indicate a potential issue and provide general information about the transaction, such as the current memory usage.

Runtime Logs are captured 15 minutes after the Vault Java SDK transaction completes. If you’ve recently encountered an error which is not captured in the runtime log, wait for the transaction to finish and check again.

Your organization’s Vault Java SDK developers can send custom ERROR, WARN, and INFO messages to the runtime logs. Learn more about working the Runtime Logs in the Developer Portal.

Runtime logs capture data in 5-minute intervals with the following limits:

  • Exceptions Logging: Maximum 10kb
  • ERROR, WARN, and INFO Logging: Maximum 40kb

If a limit is reached, the runtime log captures a LIMIT entry with the error details and stops capturing data. After the current 5-minute period elapses, logging resumes automatically.

API Usage Logs

Retrieve the API Usage Log for a single day, up to 30 days in the past. The log contains information such as user name, user ID, remaining burst limits, and the endpoint called. Users with the Admin > Logs > API Usage Logs permission can access these logs. From the Actions menu you can download a daily log as a CSV or Logfile.

Note that the daily logs may have a delay of about 15 minutes. If your log does not include appropriate data, know that your data is not lost, it is just not yet populated.

The logs are designed for troubleshooting burst limits and discovering which of your integrations are causing you to hit the limit. These logs should not be used for auditing, as they are not designed with the appropriate level of restrictions. For example, if an API request fails to enter the usage log, the API call is not prevented from executing, which would be required if this log was designed for auditing. In rare cases an API call may not show up as an entry in the log, but know that all calls are accurately reflected in your burst limit counts.

Learn more about API Usage Logs in the Developer Portal.

Queue Logs

The Queue Logs capture information about the queues running in your Vault. You must have the Configuration: Queues: Queue Log permission to view this log.

By default, the logs only capture undelivered messages. To capture information about all message delivery, you must set the Trace Queue Delivery.

Queue Log Options

Queue Logs

Here you can select queues to Trace Queue Delivery. Queues selected here will enter data into the logs for the next 20 minutes.

To begin capturing all message delivery data:

  1. On the Queue Logs page, select Edit.
  2. From the Trace Queue Delivery picklist, select the queues from which you’d like to capture data. By default, you select up to 25 queues.
  3. Click Save.

Once saved, Vault begins sending data from the selected queues to the logs. After 20 minutes, the picklist is cleared and Vault stops sending data to the logs. If you add or remove queues before 20 minutes has elapsed, Vault restarts this 20 minute period for all queues in the picklist.

Daily Logs

This section contains a log for each of the previous 30 days. After 30 days elapse, the logs begin to delete, starting from the oldest log.

From the Actions menu in the Log Date column, you can download a daily log as a CSV or Logfile.

Log Contents

To learn more about the contents of the queue log, visit the Developer Portal.

Email Log

Every inbound email event is recorded in Vault’s Email log. The previous 180 days of logs are available to view under Admin > Logs > Email Logs. The daily logs may have a delay of about 15 minutes. If your log does not include the appropriate data, know that your data is not lost, it is just not yet populated.

Logs are available as CSV files. The following information is reported in the log’s columns:

  • timestamp: When the event occurred
  • event_type:
    • EMAIL_PROCESSED: Successfully processed upon receipt
    • EMAIL_PROCESSING_FAILURE: Processing failed upon receipt, with the exception returned from the email processors listed in the details column
    • EMAIL_BOUNCED: Bounced, with a reason listed in the details column, and no record listed in email_record (as no Email records are created for bounced email)
    • EMAIL_REPROCESSED: Successfully processed after performing the Reprocess Email user action
    • EMAIL_REPROCESSING_FAILURE: Processing failed after performing the Reprocess Email user action, with the exception returned from the email processors listed in the details column
    • EMAIL_DELETED: The Delete Email user action was performed, and all subsequent columns other than email_record will be blank
  • sender_email
  • recipient_email
  • sent_time
  • email_subject
  • email_record: The Name field from the Email record created or deleted by this event. This field is blank if an Email record was not created (for EMAIL_BOUNCED events, for example).
  • details: This field shows processing exceptions returned from email processors after a failure, or one of the following bounce reasons:
  • VIRUS_DETECTED: Bounced for containing a virus
  • SPAM_DETECTED: Bounced for being spam
  • MAXIMUM_SIZE_EXCEEDED: Bounced for being over 30MB
  • UNKNOWN_RECIPIENT: Bounced for not being sent to a configured Inbound Email Address
  • SENDER_NOT_ALLOWED: Bounced for coming from an email address that doesn’t match an Approved Sender for the Inbound Email Address
  • FAILED_SPF_CHECK or FAILED_DKIM_CHECK: Bounced for failing sender verification
  • SENDER_BLOCKED: Bounced for coming from an email address on a blocklist that is maintained internally by Veeva at their discretion to prevent abuse or malicious behavior in exceptional cases