We are pleased to bring you the following additions and enhancements to Developer Portal features in 25R1.
Service Announcements are changes that may affect existing integrations. Organizations should assess these features against their existing integrations and make updates where necessary.
Over the next several releases, 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, with the option to temporarily disable Java 17 if code incompatibilities are found. 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.
When Java 17 is enabled:
Learn more about how to upgrade your code to Java 17, including solutions to common Java 17 compilation errors.
Release Dates:
See the full release schedule for more information about these release dates.
Release Date: 24R3.2; Dec 18, 2024
In the 25R1 release, we have modified the set of TLS 1.2 cipher suites supported by Vault servers, removing weak cipher suites, and adding support for TLS 1.3. These changes may affect some custom integrations, but not users accessing Vault with a supported browser. All customers and partners with affected integrations have been contacted directly by Developer Support.
Learn more about Veeva Vault cipher suite changes.
Release Date: 24R3.2; December 18, 2024
In multi-value picklist fields on objects, users can select a maximum of 100 values. Prior to this change, users could select more than 1,000 values, which resulted in a less optimal user experience and performance.
To prevent immediate integration interruption, users can still edit existing multi-value picklist fields on object records with more than 100 values selected, as long as the new number of values selected is less than or equal to the quantity currently selected. For example, an existing multi-value picklist with 150 values selected could be updated to 149 selected, but not to 151. Once updated to 149, a subsequent update to the same multi-value picklist could not have 150 values selected.
To ensure the ongoing functionality of integrations, developers need to evaluate their code to ensure all updates to multi-picklist values do exceed 100 picklist values (or the existing number of values, whichever is greater).
Additionally, this feature raises the limit for the number of possible entries that can exist in a picklist (on objects or documents) from 1,204 to 2,000.
Release Date: 24R3.2; December 18, 2024
With Custom Pages, your organization can now build completely custom user interfaces in Vault. This enables you to create specialized user interfaces for specific use cases without setting up external infrastructure. For example, with Custom Pages, your organization can build complex data entry forms, aggregated data views, and integration portal interfaces.
Developers create Custom Pages with client-side and server-side code. On the client side, developers write Custom Pages in JavaScript with their preferred frameworks and libraries. On the server side, developers can leverage the power of Vault Java SDK to retrieve and manage Vault data. Integrations can also dynamically send users to Custom Pages within an integration flow.
To create a Custom Page, developers need to:
Page component. This links the client code and server code in Vault. Custom Pages are secured with permission sets. Your code will run when a user loads the Custom Page. You can also configure a Tab or a Pagelink component to display a Custom Page in Vault.Learn more about Custom Pages.
Release Date: 25R1.0; April 11, 2025
The Component Definition Query API enables developers to build simple and scalable configuration tools using Vault API. Queries can be constructed to filter and extract component definitions at high speeds, allowing developers to store the configuration in external source code repositories.
This new API supports queries on Vault component records (vault_component__v) and retrieving their MDL (mdl_definition__v) and JSON definitions (json_definition__v). Developers can also query inbound VPK components (vault_package_component__v) for the definitions of inbound package component steps, allowing developers to understand which changes were executed as part of the package.
Component Definition Query:
POST /api/{version}/query/components
Release Date: 24R3.2; December 18, 2024
Word Formatted Outputs is a new feature that allows admins to design formatted outputs using a Microsoft Word file instead of an Adobe XFA PDF file as the input file. Learn more about the user and Admin-facing functionality of this feature in the Vault Help release notes.
This feature has added the input_file_type and output_format attributes to the Formattedoutput component type’s MDL. Existing Formattedoutput components will be migrated to the new model upon release. Vault still accepts any VPKs and MDL components using the old model and converts them to the new model upon deployment.
Global changes are features that affect multiple product areas or affect Vault holistically. For example, new functionality accessible through both Vault API and Vault Java SDK.
Release Date: 24R3.2; December 18, 2024
Roll-up fields offer a powerful way to aggregate values from child records associated with a parent object via a parent-child object relationship, such as calculated expenses in an expense report. Roll-up fields deliver these calculated values over time without manual effort. Learn more about this feature’s user and Admin-facing functionality in the Vault Help release notes.
Previously, this functionality was only available with custom SDK code. If your organization currently utilizes custom SDK code which mimics Roll-up field functionality, we encourage you to take advantage of Roll-up fields instead and deprecate your SDK code solution. Updates to Roll-up fields on parent records are considered a change on the record. However, Roll-up field updates do not invoke Vault Java SDK triggers.
In MDL, Roll-up fields now include several new attributes: rollup('true'), rollup_relationship_name, rollup_source_field, rollup_function, and rollup_filter_criteria.
You can set Roll-up fields using Record Migration Mode, but they otherwise behave as read-only. When you configure a Roll-up field, Vault calculates its value when an event occurs on the child records associated with it.
Developers can initiate a recalculation for Roll-up fields on a single object and check the status of a recalculation using Vault API. When performing a full recalculation on an object, Vault recalculates all Roll-up fields on the object asynchronously.
POST /api/{version}/vobjects/{object_name}/actions/recalculaterollups
Retrieve Roll-up Field Recalculation Status:
GET /api/{version}/vobjects/{object_name}/actions/recalculaterollups
This release brings the following changes to use the Vault Java SDK for Roll-up fields:
ObjectFieldMetadataType Enum now includes ROLLUP as an option to represent a Roll-up object field.ObjectRollupFieldType captures the supported return types for a Roll-up field: CURRENCY, DATE, DATETIME, NUMBER, PERCENT.ObjectRollupFieldFunctionType Enum captures the supported return types for a Roll-up field: COUNT, MAX, MIN, SUM.ObjectRollupFieldExpressionMetadata interface extends ExpressionMetadata and returns any configured filter expressions.ObjectRollupFieldMetadata interface provides access to metadata on a given Roll-up field.Release Date: 24R3.2; December 18, 2024
As part of this feature, we are introducing additional attributes to the Picklist component type’s MDL. The new system_managed attribute will indicate that users cannot:
However, users may be able to change the labels of the picklist values, activate or inactivate them, and change the sequencing depending on the nature of restrictions placed on system and standard picklists.
As part of this feature, picklist values will now be returned via picklist APIs and SDKs sorted ascendingly based on their designated order (MDL order attribute). Picklist values that possess the same order value will be sorted in the order they were configured.
Prior to this release, dependencies between picklist values could only be specified on the fields that leverage picklist. Because these dependencies exist on the field (not picklist), there could be differing dependencies between two fields that leverage the same picklist. As part of this release, standard picklists can now have dependencies defined on the picklist, as opposed to the field. Learn more about the user and Admin-facing functionality of this feature in the Vault Help release notes.
Picklists that have dependencies defined will present a new controlling_picklist MDL attribute that details the picklist upon which the current one is dependent. In addition to the controlling picklist attribute on the picklist, the Picklistentry subcomponents will contain a new controlling_entries MDL multi-value attribute that details which values on the controlling picklist the dependent picklist’s value is dependent upon.
The Retrieve All Picklists endpoint has been enhanced to indicate a picklist is system-managed:
GET /api/{version}/metadata/objects/picklists
The Retrieve Picklist Values endpoint has been enhanced to provide any defined system-managed dependencies:
GET /api/{version}/objects/picklists/:{picklist_name}
Picklist Interface is enhanced to return system-managed information.PicklistValueMetadataCollectionRequest.Builder Interface is created to retrieve picklist value metadata.PicklistValueMetadataCollectionResponse Interface is created to provide results from an executed PicklistValueMetadataCollection request.PicklistDependencyMetadataCollectionRequest.Builder Interface is created to retrieve picklist dependency information.PicklistDependencyMetadataCollectionResponse Interface will be created to provide results from an executed PicklistDependencyMetadataCollectionRequest.PicklistDependency Interface is created to return picklist dependency information.Vault API features added in 25R1 only affect API v25.1, unless otherwise noted.
Release Date: 24R3.2; December 18, 2024
These new endpoints allow developers to manage the SDK Debug Logs via Vault API, which can be used by external tools or to download the files without accessing the UI.
GET /api/{version}/logs/code/debug
GET /api/{version}/logs/code/debug/{id}
GET /api/{version}/logs/code/debug/{id}/files
POST /api/{version}/logs/code/debug/
POST /api/{version}/logs/code/debug/{id}/actions/reset
DELETE /api/{version}/logs/code/debug/{id}
Release Date: 24R3.4; February 7, 2025
Vault API now supports converting a basic document template into a controlled document template by specifying the template_doc_id__v, which automatically changes the value of the is_controlled__v attribute to true. These changes apply to the following existing endpoints:
Update Single Document Template:
PUT /api/{version}/objects/documents/templates/{template_name}
Update Multiple Document Templates:
PUT /api/{version}/objects/documents/templates
Release Date: 24R3.2; December 18, 2024
To optimize the performance of the Validate Session User API, starting in v25.1 the response only includes attributes stored in Vault. For example, the endpoint no longer returns the domain name and domain status. Previous versions of the API are unaffected by this change, but developers are encouraged to use the Session Keep-Alive API to keep sessions active and to upgrade to v25.1 to optimize performance when session user information is required.
Release Date: 24R3.2; December 18, 2024
Document Migration Mode now supports Document Relationships when using Vault Loader (UI and CLI) and Vault API. This feature enhances Vault performance when migrating document relationships in Veeva Promomats.
Release Date: 24R3.2; December 18, 2024
The Retrieve Package Deploy Results API now includes a URL to download a ZIP file containing all deployment success and failure logs without needing to access Vault UI.
Additionally, deployment logs are created as record attachment versions on the Vault Package (vault_package__v) object. Previously, each log file was a separate attachment. From this release, there is a single attachment, with each new log added a new version.
Release Date: 24R3.4; February 7, 2025
This feature adds the grouping_id to the Object Audit API. Vault populates the grouping_id, which indicates that the audit entries with the same ID are grouped logically.
Release Date: 24R3.2; December 18, 2024
As of this release, we deprecated the Standard Metrics: Create Document Update Job endpoint in all Vault API versions.
Release Date: 24R3.2; December 18, 2024
This feature streamlines procedure management in Vault by allowing for a Vault-level library of global Procedure Definitions that can be used to create Procedure Templates. Learn more about the user and Admin-facing functionality of this feature in the Vault Help release notes.
With this feature, a Populate Procedure Definitions endpoint is now available to create Procedure Definitions for a specific study.
POST /api/{version}/app/clinical/ctms/populate-procedure-definitions
Release Date: 24R3.4; February 7, 2025
With this feature, a new endpoint is now available for Clinical Operations Vaults to request the merge of two records on the following Global Directory objects: Person, Contact Information, Organization, and Location. Before records are successfully merged, Vault API performs validation to protect the Global Directory’s data integrity. Merging Global Directory data allows for correcting duplicate records that may exist due to migrations, integrations, or day-to-day activities.
Initiate Clinical Record Merge:
POST /api/{version}/app/clinical/objects/{object_name}/actions/merge
Release Date: 24R3.4; February 7, 2025
To support the intake of Inbox Items for Product Quality Complaints, the Intake JSON endpoint now supports the following fields on the Case Adverse Event (case_adverse_event__v) object:
type__v)affected_product__v)Release Date: 24R3.4; February 7, 2025
In MedInquiry Vaults with telephony functionality, users can now dial phone numbers from the Case and Case Contact pages. To support this in Vaults with custom telephony integrations, we’ve added the following methods to the Omniconnect JS API v25.1:
onDial: Allows the integration to register a function to do the dialingdial: Accepts a phone number and calls the function assigned in registerDialonDialError: Accepts a message string that users see in the Vault MedInquiry UI when a call fails to connectThis feature also updates the existing onConnected method to accept isOutbound: true as part of the metadata object.
Release Date: 24R3.4; February 7, 2025
Starting in v25.1, the VQL FIND() clause respects parentheses and operator precedence. This means that operations enclosed within parentheses are evaluated first, and logical conjunctions (AND) take precedence over logical disjunctions (OR).
For example, in FIND ('diabetes' SCOPE ALL AND ('insulin' SCOPE CONTENT OR 'endocrinology' SCOPE PROPERTIES)), VQL evaluates the operation in parentheses first.
Release Date: 24R3.2; December 18, 2024
With this release, you can use the new TRIM() VQL function with Picklist fields in the SELECT statement. This function removes the trailing namespace suffix from a picklist value name, such as __sys, __v, or __c. This transforms the query response for picklist names from picklist_value__c to picklist_value.
Release Date: 24R3.2; December 18, 2024
Vault now supports reference lookups (joins using dot notation) in the WHERE clause of an inner join subquery. Developers can leverage this feature to retrieve values from an additional level of separation from the main query.
Example:
SELECT id
FROM component__c
WHERE id IN (SELECT parent_component__c FROM sub_components__cr WHERE sub_component_category__cr.name__v = 'VQL')
Release Date: 24R3.4; February 7, 2025
This feature provides Vault Java SDK services to manage workflow tasks. This will enable developers to automate parts of a workflow execution. With the new services and interfaces, developers will be able to access:
Learn more in the SDK Documentation.
Release Date: 24R3.4; February 7, 2025
Developers can now send translated emails to Persons using the Vault Java SDK’s NotificationService. To accomplish this, we’ve deprecated the two existing methods for setting notification recipients and replaced them with two new methods. The new methods will accept a List<String> instead of a Set<String> and will handle duplicate detection automatically:
setRecipientsByPersons(List<String>): Sends translated emails to Persons based on their Language field value; consistent with existing behavior to send notifications to Users setRecipientsByPersonIds(Set<String>)setRecipientsByUsers(List<String>): Sends translated emails to Users based on their Language field value. No behavior change besides List<String> instead of a Set<String> setRecipientsByUserIds(Set<String>)Release Date: 24R3.4; February 7, 2025
Developers can now retrieve object metadata by the object prefix using the .withObjectPrefix() method. This is useful when trying to determine the metadata for an object based on the object record ID only, as the first three characters of a record ID correspond to the object prefix.
ObjectMetadataRequest objectMetadataRequest =
objectMetadataService.newObjectRequestBuilder()
.withObjectPrefix("00P")
.build();
Release Date: 24R3.2; December 18, 2024
From this release, developers can set the errors node of the Custom Web API’s response using the webApiContext.newWebApiFailureResponseBuilder().This allows developers to create response patterns consistent with system and standard Vault APIs.
Release Date: 24R3.2; December 18, 2024
SDK developers now have access to Query Describe metadata when using Query Service to execute and validate VQL queries. Developers can leverage this to understand the data type of the fields returned.
Release Date: 24R3.2; December 18, 2024
The PicklistRequest.Builder is enhanced so that developers can pass a language when constructing their picklist request builder. With this feature, it is now possible to retrieve picklist labels in a specified language, instead of the Vault’s base language or the user’s language.
Release Date: 24R3.4; February 7, 2025
For inbound email addresses that allow Persons or Anyone as a sender, Vault Admins now have the option to always use the specified Email Processor User when running the email processor even if the sender’s email address belongs to a Vault User.
To support this, we’ve added the new run_as_processor_user(boolean) attribute to the Inboundemailaddress component.
Release Date: 24R3.4; February 7, 2025
Vault now includes several enhancements to help reduce notification overload for users by using Summary Email notifications as a standard more frequently. Learn more about the user and Admin-facing functionality of this feature in the Vault Help release notes.
As part of this feature, the Notificationtemplate component MDL now defaults the email_preferences attribute to summary if no value is specified.
Release Date: 24R3.4; February 7, 2025
Admins can now customize page format, adjust font styling, select text alignment, and add logos when creating basic overlay templates that will apply to viewable renditions upon download. Prior to 25R1, Admins needed to leverage XFA templates to apply customizations like these to their overlay templates.
To support this, the MDL for the Overlaytemplate component type has additional attributes that store the values for the enhanced options in the component:
schema_version (read-only)header_richtextsignature_block_richtextfooter_richtextAll existing VPK Packages and MDL will be backward compatible. However, if users view the component in the UI, they will see the new editor window, and upon save, the Overlaytemplate component attributes will be stored in the new attributes. Creating new XFA templates is not supported.
Release Date: 24R3.2; December 18, 2024
This feature enables enhanced formatting options, such as the addition of logos or text styling, allowing developers to create signature page templates without Adobe XFA technology.
To support this feature, the Signaturepage component has the following new attributes that store the HTML for the appropriate parts of the signature page:
header_richtextsignature_block_richtextfooter_richtextWe’ve also added a new system-managed attribute schema_version to MDL to identify whether a Signaturepage uses the existing or new enhanced formatting options.
Upon release, existing basic templates will have their Rich Text attributes populated with data translated from existing values in header_01, header_02, signature_block_01, signature_block_02, footer_01, and footer_02, as applicable.
When schema_version is 0, existing attributes header_01, header_02, signature_block_01, signature_block_02, footer_01, and footer_02 will be used when generating signature pages using that template. Otherwise, Rich Text attributes will be used.
Any VPKs and MDL using the old header, signature block, and footer attributes will still be accepted. When schema_version is 0, richtext fields will be auto-populated with data translated from those fields upon execution. The same applies if schema_version is not 0 as long as no value is provided in the corresponding Rich Text attribute.
Release Date: 24R3.2; December 18, 2024
A circular dependency between Quality Teams and formatted outputs when deploying configuration using a VPK has been resolved by introducing a new component and subcomponent: Qualityteamlifecycleassociation and Qualityteamrolelifecycleassociation. Existing Quality Teams will be migrated to the new components automatically upon release.
Release Date: 24R3.4; February 7, 2025
In Quality Vaults, Related Record Configurations now include a new section that defines reference records to be copied when the Create Related Record action executes, greatly reducing time spent doing manual data entry.
To support this feature, the Relatedrecordsetup MDL component type now includes the copy_attachments attribute and the new Relatedrecordreferencemapping subcomponent type.
Release Date: 24R3.4; February 7, 2025
Admins can now configure the Reason for Change feature for custom objects. To support this feature, the Qualityreasonforchange component MDL has the following new attributes:
capture_field (Subcomponent)capture_type_field (Subcomponent)record_trigger (Component Reference)Release Date: 24R3.4; February 7, 2025
To support this feature, the Qualityrecordcheck component’s display_fields attribute is now conditional. This means that if the Qualityrecordcheck is for Quality Event Suggestions, display_fields aren’t required, but they will remain required for recurrence checks and duplicate checks. In addition, two additional subcomponents have been introduced to capture the field and related record suggestions configuration: Qualityfieldsuggestion and Qualityrelatedrecordsuggestion.