Viewing Admin Logs

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. Navigate to the page for the data you wish to export.
2. Optional: When viewing the Domain Audit History, set a date range using the Quick history drop-down. You can also choose a range by entering dates and clicking Get History.
3. Optional: When viewing other audit histories, choose from different filter options.
4. Click on the Actions menu and choose Export to CSV, Export to Text, or Export to PDF. If the Enable multilingual document handling option is set, only the Export to Text and Export to 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.

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.

Export and Retention 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 date range, you can export multiple times, changing the date filter each time.

Additionally, Vault only retains some logs for a limited time. Use this table to determine date range and retention limits for a given log:

Log	Date Range Limit	Retention Limit
System Audit History	4 weeks	No limit
Login Audit History	2 weeks; No limit when using Vault ID filter	No limit
Document Audit History	No limit	No limit
Domain Audit History	2 weeks	No limit
Object Record Audit History	No limit	No limit
Debug/SDK Log	1 day	30 days
API Usage Logs	1 day	30 days
Queue Logs	1 day	30 days
Email Logs	1 day	180 days

How to Filter Audit Histories

Filters are available for all audit histories except the Domain Audit History. At the top of the page, by default, the audit history is already filtered by Timestamp is 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, Vault ID, User, or Object from the drop-down. Depending on the page you are viewing, some filters may be unavailable.
2. Optional: If you selected Timestamp, select a date range 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. If you omit the Timestamp filter, then you will see the history of the specified event(s) for all time.
4. Optional: If you selected Vault ID, the operator Equals and a Vault ID will appear by default.
5. 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. If you omit the Timestamp filter, then you will see the history of the specified user(s) for all time.
6. 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. If you omit the Timestamp filter, then you will see the history of the specified object(s) for all time.
7. Optional: Click Add filter to add any of the remaining filters (Timestamp, Event, Vault ID, User, or Object).
8. Click Apply to update the table.

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. For each event, you can see the timestamp, the user making the change, the affected item, and the description. When users reorder certain components, such as document lifecycle states or user actions, Vault doesn’t capture these changes in the 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 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.
• Authenticate: Appears when a user submits their login credentials to provide an eSignature.
• User Login: A user logged in directly to the current Vault. This type also appears for unsuccessful logins (wrong passwords, etc.).
• User Logout: A user logged out of the current Vault, either by clicking Log Out or by a session timeout due to inactivity. This type excludes session timeouts that occur after the user closes the browser window or shuts down their computer.
• 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}.
• Support User: Indicates that a Veeva employee (Veeva Support, for example) logged into a customer Vault as a read-only user to investigate or troubleshoot a production issue.
• Vault Switch: Indicates that a user logged in to one Vault and then switched to another Vault without logging out and then logging in.

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:

• Enterprise Home Login
• OAuth 2.0/OpenId Connection Authentication
• SAML Authentication
• User Login
• Vault 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.

Vault does not update documents when a user saves without making any changes. This means that the document’s Last Modified Date is not changed and Vault does not create an event in the document audit history.

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

Document Audit Log Contents

The columns in the exported document audit log report the following information:

• Timestamp: Date and time when the action was performed, adjusted to your own timezone, accounting for daylight savings time.
• User Name: Username of the user who performed the action. It may show “System” for actions performed automatically by Vault.
• Full Name: Full name of the user who performed the action.
• Action: Name of the action performed on the document.
• Item: The document number.
• Field Name: Name of the document field.
• Old Value: Previous value of the field when data changes.
• New Value: Current value of the field when data changes.
• Signature Meaning: The reason a signature was required for any manifested signature.
• Workflow Name: Name of the workflow.
• Task Name: Name of the task associated with the action.
• View License: Returns a value of “View-Based User” only when the user is assigned that license type. Otherwise, returns an empty string.
• Job Instance ID: The job associated with the action.
• Document ID: Unique ID for the document.
• Version: Version of the document on which the action occurred.
• Event Description: Description of the action that occurred, showing both the previous and new values when data changes.
• On Behalf Of: If the action was performed on behalf of another user, this field represents the delegating user’s name.

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. 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.

Vault does not update records when a user saves without making any changes. This means that the record’s Last Modified Date is not changed, triggers do not execute, and Vault does not create an event in the object record audit history.

Object Audit Log Contents

The columns in the exported object audit log report the following information:

• Timestamp: Date and time when the action was performed, adjusted to your own timezone, accounting for daylight savings time.
• User Name: Username of the user who performed the action. It may show “System” for actions performed automatically by Vault.
• Full Name: Full name of the user who performed the action.
• Action: Name of the action performed on the object record.
• Item: Name of the object record.
• Field Name: API name of the object field.
• Field Label: Label of the object field.
• Old Value: Previous API name of the field value when data changes (for object and lifecycle state values).
• New Value: Current API name of the field value when data changes (for object and lifecycle state values).
• Old Display Value: Previous display value of the field when data changes.
• New Display Value: Current display value of the field when data changes.
• Record ID: Unique ID for each object record.
• Object Name: API name of the object.
• Object Label: Label value of the object.
• Workflow Name: Name of the workflow.
• Task Name: Name of the task associated with the action.
• Verdict: Outcome of the task.
• Reason: Reason associated with the verdict.
• Capacity: Capacity associated with the verdict.
• Event Description: Description of the action that occurred, showing both the previous and new values when data changes.
• On Behalf Of: Delegating user’s name, if the action was performed on behalf of another user.

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.

As part of the Veeva employee off-boarding process, Veeva inactivates the Veeva employee domain user accounts on all Vault domains, including Veeva Customer Vault domains (for any domain types). When Veeva inactivates such a domain user account, Vault creates the following event in the Domain Audit logs under the System user: “User: <User Name> made Inactive by Veeva Systems.”

Example: “Joe.doe@veevavault.com made inactive by Veeva Systems.”

Vault automatically inactivates all related active Vault user memberships when inactivating a domain user. Vault logs these Vault membership inactivations in the Login Audit history under the System user.

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 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.

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.

Log Data

By default, the debug log includes entries for all custom classes and log levels. You can narrow the results to only include certain log levels or classes by applying filters.

Log Level filters for the debug log include the following options:

• ALL: The debug log captures all log entries. This is the default setting.
• EXCEPTIONS: The debug log captures exceptions from Vault Platform and RollbackExceptions thrown by custom code.
• ERROR: The debug log captures exceptions and custom error messages created with LogService#error().
• WARN: The debug log captures exceptions, errors, and custom warnings created with LogService#warn().
• INFO: The debug log captures exceptions, errors, warnings, and custom information messages created with LogService#info().
• DEBUG: The debug log captures exceptions, errors, warnings, information, and custom debugging messages created with LogService#logResourceUsage().

Class Filters allow you to restrict debug log entries to only include entries for specific classes. These can be named entry points (RecordTrigger, RecordAction, etc.) or shared code such as user-defined classes.

To filter by class, click Add in the Class Filters section. In the dialog, select the classes you want to include, then click OK. You can include up to 10 classes.

Expiration

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.

Limits

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.
• Maximum days logs are available: 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.

Profiler Log

The Profiler Log allows developers to create SDK request profiling sessions, which allow developers to troubleshoot custom Vault Java SDK solutions and improve code quality by analyzing results at the SDK request level. Through the Vault UI or Vault REST API, developers and Vaut Admins can create profiling sessions that capture all SDK requests that occur while the session is active. Profiling sessions can be configured for either one specific user, or all users.

Users with the Admin: Logs: Vault Java SDK permission can create profiling sessions. To create a profiling session, navigate to Admin > Logs > Vault Java SDK Logs and click Create. In the Profile for User field, select a user to start a profiling session for a specific user, or leave this field blank to start a profiling session for all users. Vault starts the profiling session immediately on creation, indicated by a Status of In Progress. Profiling sessions run for either 20 minutes or up to 10,000 SDK requests, whichever comes first. To end a session early, select End Session from the profiler’s Actions menu. Once ended, a session’s Status is Processing while Vault prepares the data, which may take about 15 minutes. Once the Status is Complete, the data is available for download.

Log Data

Admins can download profiling results as a CSV through the Vault Admin UI and Vault API, which includes one row per SDK request with the following data:

• Timestamp, in UTC
• Initiating user ID and Username
• Execution ID
• Total gross memory, in bytes
• Elapsed time, in milliseconds
• CPU time, in nanoseconds

Expiration

Profiler logs expire after 30 days. At the end of 30 days, Vault deletes the log and all log files. The Days to Expiration column displays the number of days remaining until expiration.

Limits

• Only one profiling session can be active at a time. A session with any Status other than Complete is considered an active session. For example, sessions which have ended but are still Processing are considered active sessions.
• Each Vault can save up to 10 Profiler Logs at one time. After reaching the limit of 10, you must delete an existing log or wait for existing logs to expire.
• Each profiling session has a maximum duration of 20 minutes.
• Each profiling session can capture a maximum of 10,000 SDK requests.

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 Data

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.

Limits

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

• Exceptions and system warnings logging: Maximum 10 KB
• ERROR, WARN, and INFO logging: Maximum 40 KB

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

You can 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 permission can access these logs from Admin > Logs > API Usage Logs.

The API Usage Logs page includes the Date, Successes, Failures, and Warnings encountered during an API request. From the Actions menu of a log entry, you can Download in CSV format or Download in Logfile format.

Daily logs may have a delay of about 15 minutes. If your log does not include appropriate data, 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 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

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.

Queue 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.

Email Log Contents

The columns in the exported CSV file report the following information:

• 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
• 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