We are pleased to bring you the following additions and enhancements to Developer Portal features in 25R2.
Service Announcements are changes that may affect existing integrations. Organizations should assess these features against their existing integrations and make updates where necessary.
In 25R2, Veeva is upgrading Vault Java SDK to Java 17. Java 17 includes optimizations that can improve performance and efficiency compared to Java 8, allowing for reduced resource usage.
In this release, Vault is auto-enabling Java 17 compilation in all Vaults. When enabled, Vault compiles new SDK code deployments with Java 17 instead of Java 8. This means that enabling Java 17 does not automatically test your custom code for compatibility, as existing code is not recompiled. To test your code for compatibility with Java 17, redeploy any existing custom code to recompile with Java 17. We are also adding additional Java 17 syntax has to the JDK allowlist.
When Java 17 is enabled:
Learn more about how to upgrade your code to Java 17, including solutions to common Java 17 compilation errors.
See the full release schedule for more information about these release dates.
In 25R3, Veeva will migrate from the DigiCert Legacy Root Certificate to the DigiCert G2 Root Certificate for signing Vault SSL Certificates. This is to align with DigiCert and Mozilla’’s end of life for the Legacy Root Certificate in April 2026. Customers with integrations built on Java 1.7 and below may be affected, and are encouraged to evaluate their integrations for G2 certificate support.
Release Date: May 30, 2025
We are pleased to bring you the following additions and enhancements to Developer Portal features in 25R1.3.
This feature introduces window.vaultLocation, which allows Custom Page developers to control navigation and history in the same way as using window.location when in control of the entire HTML document.
This feature also introduces UrlService, which enables developers to generate URLs to documents, object records, lists, and Custom Pages.
Action Triggers is a new Admin-configurable feature which can perform operations when records have changed, which can eliminate the need to build custom SDK Recordtriggers to execute these operations.
A new component type, Actiontrigger, has been introduced to manage the configuration of Action Triggers. Each Actiontrigger component record stores the object name, event type (before/after insert, update, delete), and the action to initiate. Actiontrigger component records can be deployed using Vault API and Vault UI.
Learn more about the user and Admin-facing functionality of this feature in Vault Help.
Vault Admins can now enable Direct Data API in Vaults without needing to submit a ticket to Veeva Product Support. Once enabled, Vault automatically generates Full, Log, and Incremental files. The first extract may take up to 24 hours and once Direct Data API is enabled, the feature cannot be disabled.
Direct Data API now includes a md5checksum attribute for each file part. This allows developers to build integrations that can verify all data was properly downloaded.
Developers can now build integration and migration tools for Veeva Clinical that can update the study migration status in bulk, enabling or disabling Study Migration Mode. This means fewer API calls are needed to enable and disable Study Migration Mode. Studies are updated asynchronously and results can be queried using VQL.
Vault Admins can now use Vault Tokens in expressions. This allows consistent configuration across Vaults and sandboxes while using environment-specific variables to resolve expressions. For example, an Admin can create a custom Vault Token, external_url__c, that points to different endpoints for production versus sandbox, but allows an object formula field to be defined using @Vault.external_url__c.
Document Owners can now delete annotations using Vault API and Vault Java SDK. Prior to 25R2, only the person who created an annotation could delete it. This enhancement removes the additional effort required to delete annotations.
This feature must be enabled by a Vault Admin, and the annotations can only be deleted if the user has the appropriate permissions. Learn more about the user and Admin-facing functionality of this feature in Vault Help.
Developers can now retrieve deleted attachment IDs for documents and object records using Vault API. Deleted attachment metadata is available for 30 days.
Vault now supports downloading the extracted text from source document content. This allows developers to build integrations to support AI use-cases without needing to download MS Word or PDF documents and perform additional processing to extract the text.
To help with troubleshooting job errors, this release introduces two new job statuses:
TIMEOUT: This status represents a job instance that was QUEUED or QUEUEING, but timed out before it could begin to run. Previously, this returned an error of FAILED_TO_RUN.COMPLETED_DUE_TO_INACTIVITY: This status represents a job instance which was RUNNING, but timed out before it completed successfully. Previously, this returned an error of ERRORS_ENCOUNTERED.These new statuses may appear when using Vault API to retrieve a job status. You can also filter by these new statuses when retrieving job histories, and query them with VQL.
This feature introduces three (3) new public endpoints to manage HACCP plan translations by allowing for the export, retrieval, and import of all translatable fields from a HACCP Plan record and its related transactional records. The new endpoints process JSON files to execute asynchronous jobs that handle the translation export and import operations. These APIs facilitate the integration of third-party translation services to deliver an automated end-to-end translation process of a HACCP plan, ensuring that users who aren’t fluent in English can view HACCP plans in their local language.
View these endpoints in the v25.2 API reference.
This release standardizes customer environments by requiring object lifecycles across Quality Cloud Vaults to have certain lifecycle state types available, as these state types are needed for various application functions. Previous releases allowed developers to inactivate these lifecycle state types through Vault API or MDL (VPKs). With this feature, these lifecycle state types can no longer be inactivated with Vault API or MDL.
Developers should examine their custom code and modify any code which attempts to inactivate these lifecycle state types. Any code which attempts to inactivate these lifecycle state types will no longer execute.
The affected lifecycle state types are:
approved__v)apqr_program_approved__v)proposed_apqr_approved__v)approved_state_type__v)approved_template__v)ia_template_approved_template__v)cancelled__v)closed__v)cycle_time_start__v)cycle_time_stop__v)fulfilled_state_type__v)in_requalification_state__v)in_progress__v)no_impact_identified__v)pending_regulatory_assessment__v)published_state_type__v)regulatory_assessment_complete__v)qualified_state__v)This feature does not affect the function of these lifecycle state types or the ability to map them to different lifecycle state types.
As part of OpenData Clinical’s “Investigator Affiliation to Multiple Sites” feature, Vault is introducing an endpoint that will list all investigator-site affiliations in OpenData Clinical for a specific investigator or site, as well as a separate endpoint to specify, for a given investigator, which site affiliation they consider primary for their purposes. The additional endpoints allow developers to more fully interrogate OpenData Clinical and adjust how they use that data in their Vault.
This feature allows VQL developers to programmatically discover and describe query targets, fields, and relationships.
SHOW TARGETS returns the queryable targets.SHOW FIELDS FROM {query target} returns the queryable fields on the specified query target.SHOW RELATIONSHIPS FROM {query target} returns the queryable relationships on the query target.This is also supported in Vault Java SDK QueryService.
Developers can now access all document field metadata when building solutions with SDK. DocumentService provides builders to filter document fields by requiredness, activeness, and document type.
With this feature, we’ve added a new attribute called adminCancellable to the @JobInfo annotation. This determines if an SDK job instance is cancellable by an Admin in the Vault’s Job Status page.
Previously, the adminConfigurable annotation determined if an SDK job was cancellable. The new adminCancellable annotation ensures that adminConfigurable is used to determine whether a job can be called with custom SDK code or configurable as a Job Definition in the Vault UI, and isn’t tied to job instances also being cancellable.
In the Vault UI, Vault Java SDK Logs have now been renamed to Developer Logs. Integrations that download debug and runtime logs are not impacted by this change.
This feature introduces a new attribute for the Qualityinboundemailaddressconfiguration component named email_thread_detection. The attribute can be set to MATCH_ON_ROOT_MESSAGE_ID or MATCH_ON_MESSAGE_ID. If neither is specified, the default value is MATCH_ON_MESSAGE_ID. Learn more about the user and Admin-facing functionality of this feature in Vault Help.
This feature enables Vault UI users to use a Select All button while relating multiple records at once in a related object section. Learn more about the user and Admin-facing functionality of this feature in Vault Help.
This feature introduces a new attribute for the Object component named relate_records_select_all. This attribute can only be used for join objects, and it can only be set to true if multi_select is also set to true. For simple join objects, this attribute is always set to true. Otherwise, this attribute is not allowed. If set to true, Vault UI users can use the Select All button while relating multiple records at once in a related object section.
Release Date: April 25, 2025
We are pleased to bring you the following additions and enhancements to Developer Portal features in 25R1.2.
Direct Data API now includes an extract that captures document relationships in Direct Data files. This allows developers to represent the relationship between documents, such as based on, supporting, and so on, in downstream systems.
Direct Data API is designed for resiliency. When errors occur, Vault retries the Direct Data job. Starting in v25.2, Vault will return error information, including the next retry date (next_retry). This allows developers to build resilient integrations that can retrieve the file on or after the next retry date.
Direct Data API now has a new job called Direct Data Staging, which runs hourly. It is responsible for the initial staging of data and monitoring any configuration changes that happen in Vault.
When using Vault API or Vault Java SDK to create, update, and delete object records, developers who use an external ID now have access to the unique value supplied in the request payload. This means custom solutions can use external IDs to track success or failure without having to maintain a list of records supplied by the request. Additionally, when upserting records, Vault returns the event type (created or updated) in the response.
Enhanced endpoints and interfaces:
PositionalRecordIdIn this release, we’ve added a new object class securitytree that allows configuring security trees. When Security Tree objects are created, a corresponding User Tree Assignment object is created automatically with the name defined in the user_tree_assignment_object_name attribute. Developers can then assign the Security Tree object to objects using the security_tree_object attribute. Assigning a security tree automatically generates a Tree Assignment object with the name defined in the tree_assignment_object_name attribute.
Metadata provided in Vault API and Vault Java SDK has been enhanced to return the tree security configuration, and roles assigned using Tree Security are returned when using Object Role APIs and RecordRole Java SDK Services.
A new attribute, replicate_sharing_from_parent, is available on the Object.Field component and allows developers to configure sharing settings to be replicated from the parent object. When this setting is enabled, Custom Sharing Rules and Matching Sharing rules are deleted, and integrations cannot use Vault API or Vault Java SDK to add manual roles. Developers should evaluate existing custom solutions before enabling this setting.
The Retrieve Object Record Collection will not be supported when using API v25.2+. Older API versions are not affected. Instead of this API, developers should use Direct Data API or VQL for optimal performance.
The Retrieve Document Version Notes as CSV API will not be supported when using API v25.2+. Older API versions are not affected.
Instead of this API, developers should use the Read Annotations APIs to retrieve document annotations by document or by ID:
The Retrieve Anchor IDs API will not be supported when using API v25.2+. Older API versions are not affected.
Instead of this API, developers should use the Read Annotations APIs to retrieve anchor annotation IDs by document or by ID:
Integration accounts no longer need admin permissions for Quality Teams to use the Manage Quality Team Assignments API. Users are still required to have API access and edit permissions for Quality Team Relationships on the specified records.
Learn more about the user and Admin-facing functionality of this feature in Vault Help.
Developers can now access the Pre-Default Object Reference Field Setting metadata for object fields using ObjectMetadataService.
Using MDL, administrators can now configure the Inboundemailaddress component to notify Vault User and Person senders if the Email record is created in a Bounced state. A new attribute, send_bounce_notification, has a default value of false.
A new attribute, clear_rendition_properties, has been added to the Renditionprofile component that allows developers to configure rendition profiles to remove document metadata from generated renditions. When set to true (default = false), renditions will not include document metadata.