We are pleased to bring you the following additions and enhancements to Developer Portal features in 23R1. REST API features added in 23R1 only affect API v23.1, unless otherwise noted.
Release Dates:
Vault is scheduled to rollover the signing certificate used to sign SAML Single Sign-on requests and Spark messaging connections. There is no expected downtime.
Your IT organization must ensure that the new certificate is configured on your Enterprise Identity Provider system prior to the New Certificate Rollover Event on March 3, 2023. Please ensure that your Spark messaging integrations do not cache the old certificate. Failure to utilize the new certificate by this date may cause login issues for SAML users, and Spark messaging integrations may fail.
Learn more about the action required for the certificate rollover process in Vault Help.
Release Dates:
The 22R2 release added the Run Custom Code as Java SDK Service Account setting to Admin > Settings > General Settings. This setting is not available in pre-release Vaults. If this setting is enabled in your Vault:
The Java SDK Service Account user appears in the Users & Groups Admin tab in all Vaults, but does not affect license counts.
In 22R2, this setting was off by default, but Admins could enable it from the General Settings page. In 22R3, this setting is on by default, but Admins can disable from the General Settings page. In 23R1, this setting will be on in all Vaults and will no longer appear on the General Settings page.
Release Date: February 10, 2023
This enhancement allows API users to update and upsert object records to any lifecycle state, bypassing validation rules for migrating records into Vault from an external system.
API users of Vault Loader can now leverage Record Migration Mode to update and upsert records in a non-initial state while bypassing reference constraints and validation rules.
This feature allows Admins to upgrade a snapshot on an older release version to match the release version of the source sandbox Vault.
POST /api/{version}/objects/sandbox/snapshot/{api_name}/actions/upgrade
With this release, we’re deprecating the Retrieve SubmissionsArchive Binder API endpoint. As of 22R3.4, the new Submissions Archive Viewer does not rely on the binder for the hierarchy structure, making this endpoint obsolete.
GET /api/{version}/vobjects/submission__v/{submission_id}/actions/viewer
With this release, the Delete Single Document and Delete Single Document Version APIs now perform validation when attempting to delete documents with Publish for Veeva CRM (CLM) set to Yes. This provides parity with the Vault UI and prevents deletion when the document is associated with one or more object reference.
Given an existing study with Site Fee Definitions or an eligible Site Fee Template, Vault Payments customers can now automatically generate Site Fee Definitions for a new study. Developers can also initiate this action with the new Populate Site Fee Definitions API:
POST /api/{version}/app/clinical/payments/populate-site-fee-definitions
To provide parity with document audit trails generated in the Vault UI, the Retrieve Audit Details API now supports filtering based on events when retrieving document_audit_trail details. Add theevents parameter and provide a list of the events you want to filter on. For example, to retrieve audit details for documents where either a single version or all versions have been deleted:
GET /api/{version}/audittrail/document_audit_trail?events=DocSingleVersionDeleted,DocAllVersionsDeleted
You can find a list of supported document audit events in Vault Help.
To ensure Vault performance, Vault now enforces new timeout and concurrency rules. When VQL queries fail due to timeout, Vault will prevent the same query from being executed again for 24 hours. Additionally, VQL queries are limited to five (5) concurrent queries (and query page requests) for the same Vault user. This change only applies to v23.1+ and does not affect existing integrations.
Developers can now choose to send in-app notifications only or email notifications only by using the setNotificationMode() method in the NotificationParameters interface. The setNotifyByEmailOnly() method is deprecated in this release.
Developers have access to two new SDK Request Context Users: Initiating User and Request Owner. Initiating User will always return the “user-at-the-keyboard” unless the SDK request is initiated by Vault (scheduled job). Request Owner gives developers access to configured users such as Job and Message Processor Owners. Additionally, users can use HttpService and execute local API requests as these new users. Current User has been deprecated and is discouraged from use.
Developers can now determine if the current SDK Request is taking place during a workflow, and if so, gain access to the Workflow ID, Workflow Name, and the Workflow Owner ID.
Release Date: December 9, 2022 Postponed to December 15, 2022
This feature introduces two new sandbox sizes, “Small” and “Full”. Existing Sandboxes will be categorized as “Large”. The size of a sandbox determines the amount of data a sandbox can store. Admins are able to interact with sandboxes using new endpoints.
The Recheck Sandbox Usage Limit endpoint allows Admins to recalculate data usage of a sandbox Vault.
POST /api/{version}/objects/sandbox/actions/recheckusage
The Change Sandbox Size endpoint allows Admins to change the size of a sandbox Vault.
POST /api/{version}/objects/sandbox/batch/changesize
A sandbox snapshot is a copy of a sandbox Vault that can store configuration and optionally data at a given point of time. Snapshots can be used to create or refresh sandbox Vaults. Admins are able to interact with snapshots using the following new REST API endpoints:
The Create Snapshot endpoint creates a snapshot for a sandbox by providing a source sandbox.
POST /api/{version}/objects/sandbox/snapshot
The Retrieve Snapshots endpoint retrieves information about snapshots managed by the authenticated Vault.
GET /api/{version}/objects/sandbox/snapshot
The Delete Snapshot endpoint deletes a snapshot for an active sandbox.
DELETE /api/{version}/objects/sandbox/snapshot/{api_name}
The Upgrade Snapshot endpoint upgrades a snapshot to match the release version of the source sandbox Vault.
POST /api/{version}/objects/sandbox/snapshot/{api_name}/actions/upgrade
The Upgrade Snapshot endpoint was postponed to a future release.
The Update Snapshot endpoint recreates a new snapshot for the same sandbox Vault. This action replaces the existing snapshot with the newly created one.
POST /api/{version}/objects/sandbox/snapshot/{api_name}/actions/update
The Create a Sandbox from a Snapshot endpoint creates a sandbox from the available snapshots.
POST /api/{version}/objects/sandbox
The Refresh a Sandbox from a Snapshot endpoint refreshes a sandbox from a snapshot.
POST /api/{version}/objects/sandbox/{vault_id}/actions/refresh
With this release, Vault Loader users can now leverage the MAXROWS andSKIP VQL clauses to page through and retrieve large record sets. This feature is supported in the Vault UI, CLI, and API.
This enhancement allows developers to use a picklist field as a unique field (i.e.: idParam) when upserting object records through Vault Loader or the Vault Rest API. Because the Vault Loader UI always uses the most recent API version, this change also affects Loader jobs created in the Vault UI in General Release Vaults on version 22R3.0.
In API v23.1+, object workflows now require values for required field prompts when starting a workflow and completing a task.
Standard Vault Connections will no longer be referenceable in custom Java SDK code because each is now set to “System Managed”.
Vault now supports tracking inbound REST API integrations using External Connections. The URL field is no longer required during configuration to accommodate inbound only connections. Vault Admins can configure Connection Client records that allow developers to identify REST API integration using a unique Client ID.
With this release, developers can leverage DateTime fields as triggers for Date Based Document and Object Operation type Jobs.
Multi-record workflows now support the execution of Vault Java SDK RecordActions in system action steps.
This enhancement allows developers to detect when a record trigger was triggered within migration mode either through API or Vault Loader. Developers can use this to build new conditions, such as skipping any operations that would not be needed for migrated records.
Query Governor now returns a response status of WARNING when it detects manual pagination and FAILURE when manually paginating more than 10k records. Manual pagination is the use of PAGEOFFSET in the query string. Instead of manual pagination, developers should use the next_page and previous_page URLs returned in the responseDetails of the query response. This change only applies to v23.1+ and does not affect existing integrations.
This feature adds the Tabcollection component type. Admins can group related tabs together in a Tab Collection, such as tabs for certain roles or tasks. Users can then access the tab collection through the new Tab Collections menu in the Vault UI.