Developer Features in 24R3
Filters
Application Family
Tags
We are pleased to bring you the following additions and enhancements to Developer Portal features in 24R3.
Service Announcements
Section link for Service AnnouncementsService Announcements are changes that may affect existing integrations. Organizations should assess these features against their existing integrations and make updates where necessary.
Java 17 for Vault Java SDK: Optional Enablement
Section link for Java 17 for Vault Java SDK: Optional EnablementOver the next several releases, Veeva is upgrading the Vault Java SDK to Java 17. In addition to new features, Java 17 includes optimizations that can improve performance and efficiency compared to Java 8, allowing for reduced resource usage.
In this release, Developers and Admins can optionally enable Java 17 for Vault Java SDK to test their custom code for compatibility with the new Java version. We recommend developers test their code using Java 17 as soon as possible. Enabling Java 17 does not automatically test your custom code for compatibility.
When Java 17 is enabled:
- Existing custom code deployed to your Vault is not affected.
- Updates to (or re-deployment of) existing code will cause the code to compile with Java 17 instead of Java 8.
- New code deployed to your Vault will compile with Java 17.
Release Dates:
- 24R2.3; September 27, 2024: Developers and Admins can optionally enable Java 17 to test their custom code for compatibility.
- 25R1; April 4, 2025: Vault will auto-enable Java 17, with the option to disable if code incompatibilities are found.
- 25R2; July 25, 2025: All custom Vault Java SDK code will use Java 17.
TLS Cipher Suite and Version Changes
Section link for TLS Cipher Suite and Version ChangesBeginning with the 25R1 release, Vault will add support for TLS 1.3 and no longer support CBC cipher suites:
ECDHE-RSA-AES256-SHA384ECDHE-RSA-AES128-SHA256
These changes may affect some custom integrations, but not users accessing Vault with a supported browser.
All customers with affected integrations will be contacted directly by Veeva Developer Services.
Learn more about Veeva Vault cipher suite changes.
Global Changes
Section link for Global ChangesGlobal 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.
Vault Loader CLI Java 17 Support
Section link for Vault Loader CLI Java 17 SupportIn order to use the latest version of the Vault Loader CLI, developers need to ensure that Java 17 is available in the environment. Developers can continue to use older versions of Vault Loader CLI with Java 8.
Yes/No Checkbox Field Enhancement
Section link for Yes/No Checkbox Field EnhancementYes/No fields using the Show as checkbox option now support null values. This means checkbox fields support three possible values: true, false, and null. This feature may impact existing integration code which assumes this field’s value can never be null. To help mitigate impact, all existing checkbox fields that do not have a default value will be updated with a default value of false.
Starting in this release, creating a new record with an optional checkbox field that does not have a default value will now have a null value. Prior to this release, checkbox fields with no value would always save as false, which means the field value would never be null.
Starting in v24.3, developers can use Vault Loader, the API, and the SDK to set checkbox field values to null. It is not possible to set checkbox values to null through the Vault UI.
Learn more about the user and admin-facing functionality of this feature in the Vault Help Release Notes
Migrate Document Usage Object to Raw Object
Section link for Migrate Document Usage Object to Raw ObjectThe Document Usage object captures detailed metrics on user actions, such as viewing, copying, and downloading documents.
To improve performance in Vaults and ensure scalability, this object is being migrated to a raw object. This should have no impact on integrations that query this object.
Learn more about the Document Usage object in Vault Help
Attachment Fields
Section link for Attachment FieldsAttachment fields are a new field type for Vault objects that allow users to attach a single file (up to 100 MB in size) to a field on an object record. Admins can create up to 15 custom attachment fields per object.All files used in attachment fields are assigned a unique file handle, which can be used as a file ID.
Developers can upsert object records with attachment fields. You must first upload the file to the staging server, and then provide its file path in the body. There are new APIs to update and download attachment field content. You can also access file metadata using new VQL functions that return the file name, MIME type, MD5 checksum, or file size of the file in an attachment field. File content will not be indexed and will not be available for any query operation.
Attachment fields are supported in the Vault Java SDK, allowing developers to inspect file metadata and copy file content to other attachment fields, object attachments, documents, and document attachments. Attachment field content is not accessible in the SDK. Learn more in the Javadocs
Learn more about attachment fields in Vault Help
Field Subtypes
Section link for Field SubtypesField Subtypes allow users to view and enter values in specific formats, like Email or Time. Learn more about the user and admin-facing functionality of this feature in the Vault Help Release Notes
Field values are still stored according to existing Data Types, but Developers can check the subtype() and format_mask() attributes of the subcomponent MDL to determine the field subtype. This allows Developers to understand the purpose of the field and represent it accordingly outside of the system. SDK developers can learn more in the Data Type Map.
Object Type Descriptions
Section link for Object Type DescriptionsAdmin users can now provide descriptions for object types, which can be useful for providing additional context when creating or editing object types. The Objecttype component definition now includes a new attribute, description, that can store text up to 1,000 characters.
In Vault Java SDK, developers can use the ObjectTypeMetadata interface to retrieve the information stored in this attribute.
Workflow Participants: User Reference Fields, User Groups, and Task Prompts
Section link for Workflow Participants: User Reference Fields, User Groups, and Task PromptsWorkflow participants in workflow start steps can now be configured based on user fields on object records or user groups (manually created and standard user groups). This allows Admins to auto-start a workflow, assign tasks to predefined users, send notifications, or update sharing settings on the record.
Admins can also now configure prompts to workflow task owners to select additional participants as part of their task completion.
Developers can query workflow participant information using VQL and retrieve and set participant values using Vault API and Java SDK. This allows integrations and custom SDK solutions to access and define participant values based on custom business rules.
Persistent ID for Annotations
Section link for Persistent ID for AnnotationsVault now automatically creates a unique Persistent ID for all new annotations and existing annotations that are either updated or brought forward after the release. This ID persists across versions when annotations are brought forward. Users will be able to see the ID in the Anchor info card and in the Select Anchors dialog box.
The introduction of Persistent IDs allows us to reliably prevent the Bring Forward Annotations action from creating duplicate annotations. Upon Bring Forward Annotations, any annotation in the source version whose Persistent ID matches an existing annotation in the target version will not be brought forward.
The Persistent ID is queryable (read-only) via Vault Java SDK and Vault API. It is added to new and updated annotations when creating and editing them in Vault API.
Learn more about working with annotations in the Vault Java SDK.
Report Configuration Migration Enhancements
Section link for Report Configuration Migration EnhancementsThis feature improves the configuration migration experience for Admins by leveraging Name (name__v) values rather than Record IDs (id). This allows Vault to provide clear messages for common report migration issues, reduce potential errors, and export the report MDL with object reference filters from a cloning environment. With this change, if an object record that is present in the target system but does not have the same Record ID as it did in the source system, it no longer results in errors or blanked-out filters. Instead, the system establishes the link using the name of the object record.
When deploying reports with references to non-unique objects, you must confirm the selected values after deployment.
In MDL, the definition XML for the vrp:whereItem will have the attribute rightValue populated with the list of names.
Unique Object:
<vrp:whereItem action="IN" leftValue="an_object_with_object_types__c.a_unique_object__c" rightValue="UO-01;;;UO-02;;;UO-03;;;UO-04" labelLanguage="en" type="PROPERTY" rightValueType="VALUE" runtime="false" />Non-Unique Object:
<vrp:whereItem action="IN" leftValue="an_object_with_object_types__c.a_nonunique_object__c" rightValue="NUO;;;NUO;;;NUO;;;NUO" labelLanguage="en" type="PROPERTY" rightValueType="VALUE" runtime="false" />Vault API v24.3
Section link for Vault API v24.3Vault API features added in 24R3 only affect API v24.3, unless otherwise noted.
Global Vault API Changes
Section link for Global Vault API ChangesGlobal Vault API changes are features that affect Vault API holistically rather than specific endpoints. For example, changes to API burst limits.
Record Migration Mode Enhancements
Section link for Record Migration Mode EnhancementsTo improve the capabilities of record migration, we have enhanced Record Migration Mode to allow more control over creating and updating records.
When setting the X-VaultAPI-MigrationMode to true, or selecting Record Migration Mode with Vault Loader, Vault allows setting system fields (ID, Created By, Created Date, Modified By, Modified Date) and bypasses all rules except:
- Fields are validated against the proper data type (String, Number, Date, etc.).
- Object types and object type fields are enforced.
- Lifecycle states must exist but can be Active or Inactive. If no state or state type is specified, records are created in their initial state.
- The system allows setting the ID for the record on create but not on update.
Record Migration Mode allows migrators to bypass picklist dependencies, set object type and document references to inactive values, and change the object type of Records.
Record Migration Mode now includes support for user__sys.
Additionally, we’ve introduced a new X-VaultAPI-NoTriggers header. When set to true, it bypasses all system, standard, and custom triggers when using Record Migration Mode.
Users must have Migration Mode permissions to use the X-VaultAPI-MigrationMode or X-VaultAPI-NoTriggers headers.
Learn more about Record Migration Mode in Vault Help
New Platform Endpoints
Section link for New Platform EndpointsThese new endpoints are only available in API v24.3, unless otherwise noted. To take advantage of these new endpoints, you must use API v24.3.
Configuration Migration Mode API
Section link for Configuration Migration Mode APITo help automate deployments, we are introducing two new API endpoints that allow developers to enable or disable Configuration Mode. Enabling Configuration Mode locks all non-Admin users from accessing Vault. Users with the Vault Owner or System Admin security profile can continue to work in Vault through the UI and API.
/api/{version}/services/configuration_mode/actions/enableView this endpoint in the v24.3 Vault API Reference.
/api/{version}/services/configuration_mode/actions/disableView this endpoint in the v24.3 Vault API Reference.
Existing Platform Endpoints
Section link for Existing Platform EndpointsIn this release, we’ve introduced new functionality to our existing endpoints. The new functionality for existing endpoints are only available in API v24.3, unless otherwise noted. To take advantage of these new features, you must upgrade your integration’s API version.
Direct Data API - Workflow Support
Section link for Direct Data API - Workflow SupportIn an effort to further improve the Direct Data API, with this release, Direct Data files now contain extracts for workflows. This includes legacy workflows, with the following breakdown:
Workflows:
workflow__sysworkflow_item__sysworkflow_task__sysworkflow_task_item__sys
Legacy workflows:
active_legacy_workflow__sysactive_legacy_workflow_task__sysinactive_legacy_workflow__sysinactive_legacy_workflow_task__sys
With the addition of workflow data, Admins must assign the Application: Workflow: Query permission to the user retrieving the Direct Data file in addition to the currently required permissions.
Vault Licensing API application_name returns API names
Section link for Vault Licensing API application_name returns API namesStarting in this release, when obtaining the Licensing information via API, the Retrieve Application License Usage API will return the API Name instead of the legacy values:
- Before: Legacy value, for example,
pmPromoMats_v - After: API name, for example,
pm_promomats__v
Create Single Document API: Enforce Document Template Limits
Section link for Create Single Document API: Enforce Document Template LimitsIn 24R1, we introduced Document Template Limits. Starting in 24R2, these limits are also enforced in all versions of the Create Single Document API.
/api/{version}/objects/documentsAdd Annotation ID to Link Target Object
Section link for Add Annotation ID to Link Target ObjectVault now allows API users and integrations to create valid Link Target (link_target__sys) object records with a reference type of anchor by providing just the Annotation ID (annotation_id__sys), Suggested Link Target Type (suggestedlink_link_target_type__v), and Document Version ID (document_version_id__v).
When the annotation ID is populated, Vault completes any anchor-related fields in the Link Target object record based on the annotation ID provided.
API users and integrations can retrieve the annotation ID for the intended anchor annotation via the Document Annotations APIs and then use the Create Object Records API to create the link_target__sys object records. This allows the API user to create valid anchor type link target records without ever needing to know the required anchor ID.
Archive Notifications after Three Months
Section link for Archive Notifications after Three MonthsNotifications sent from Vault are now archived after three months, instead of two years. Learn more about the user and admin-facing functionality of this feature in the Vault Help Release Notes
Starting in API v24.3, requests to the Retrieve Email Notification Histories API using the start_date and end_date parameters will return up to three months of notifications compared to the prior limit of two years. Users can still request a full notification history once every 24 hours with the all_dates parameter.
Support Creating 500 GB Documents via API
Section link for Support Creating 500 GB Documents via APIFor all versions of the API, this feature increases the file size limit from 4 GB to 500 GB when using the following endpoints:
Name Support in Documents APIs
Section link for Name Support in Documents APIsPrior to this release, Vault API document endpoints only accepted label values as input for specific fields. However, labels are not unique and may result in duplicates. To avoid encountering errors due to duplicate labels, you can now provide name values as input for the following fields:
- Document Type (
type__v) - Subtype (
subtype__v) - Classification (
classification__v) - Lifecycle (
lifecycle__v) - Status (
status__v) - All standard and custom picklist fields
For example, providing type__v=promotional_material__c in your request instead of type__v=Promotional Material creates a document of the indicated document type.
These changes apply to the following endpoints:
-
Create Single Document
- Create Document from Template
- Create Content Placeholder Document
- Create Unclassified Document
- Create Multiple Documents
- Create Multiple Document Versions
- Update Multiple Documents (only when updating picklist values)
- Create Binders
Veeva Safety
Section link for Veeva SafetyFaster Intake Integrations with JSON API
Section link for Faster Intake Integrations with JSON APICase Narratives and Transmission information, such as origin, can now be ingested using the Intake JSON API:
/api/{version}/app/safety/ai/intakeDevelopers can include narrative text in the JSON body to automatically create a Case Narrative Document on import. Fields can also be mapped to the Inbound Transmission, such as Sender Comments. This enhancement reduces the number of API calls needed to transmit a Case.
Deprecate the Receive E2B API Endpoint
Section link for Deprecate the Receive E2B API EndpointThe Receive E2B API endpoint was replaced several years ago with a new endpoint to import Inbox Items from an E2B (R2) or (R3) file containing one or more Individual Case Safety Reports:
/api/{version}/app/safety/intake/inbox-itemIn this release, the use of the Receive E2B API endpoint is disabled for all Vaults.
MedInquiry: Telephony Support
Section link for MedInquiry: Telephony SupportTelephony Support: Conversations
Section link for Telephony Support: ConversationsAs part of Veeva Medical’s Telephony Support: Conversations feature, there are new API methods that facilitate integrations between MedInquiry and telephony providers. This feature enables MedInquiry users to answer phone calls and live chat requests within Vault.
While Vault provides a standard integration to Amazon Connect, other CTI Applications can be integrated using the new OmniConnect JavaScript API.
Learn more about the user and Admin-facing functionality of this feature in the Vault Help Release Notes
VQL Date Literals
Section link for VQL Date LiteralsVQL queries now support date literals. Instead of providing a Date or DateTime value in the VQL query, you can supply literals such as TODAY, THIS_MONTH, and DAYS_AGO:n.
This allows developers to run the same query with dynamically changing date values, which previously required a dedicated function in integrations.
Learn more about VQL date literals.
Strict Matching Adjustments
Section link for Strict Matching AdjustmentsWhen you search for documents or object records using the FIND clause, Vault applies rules for how many of those terms must match for an item to be a result. In this release, we are adjusting these rules to allow more results to be returned (making it slightly less strict), without allowing so many items to match that the result set is too large to be useful. With the new rule, 70% of search terms must match for an item to be returned as a result (rounded down).
The most noticeable change is that two terms only require one term to match instead of both. The remaining changes are a subtle difference from today’s rules whereby searches with four or more terms require one fewer term to be considered a match.
This rule that 70% of the terms must match is easier to understand than the previous ruleset, allows a slight increase in the number of results returned, and prevents items from being unexpectedly omitted.
Learn more about strict matching and Vault search settings in Vault Help
Vault Java SDK
Section link for Vault Java SDKJava SDK Debugger Dependency
Section link for Java SDK Debugger DependencyDevelopers are now required to include an explicit reference to the SDK debugger dependency to debug custom code. The following should be included in the project's pom.xml file:
<dependency>
<groupId>com.veeva.vault.sdk.debugger</groupId>
<artifactId>vault-sdk-debugger</artifactId>
<version>${vault.sdk.version}</version>
<scope>runtime</scope>
</dependency>Custom Web API
Section link for Custom Web APIDevelopers can now create custom API endpoints using the Vault Java SDK to fulfill specific business requirements. Custom APIs accept JSON or form data with a single binary content file and return response status and either JSON or binary content for existing Vault documents or record attachments.
Custom WebAPIs are given a name that is used in the URI:
/api/{version}/custom/{webapi_name} and must specify a minimum API version. Developers are responsible for versioning their changes.
Custom WebAPIs must be assigned to WebAPIGroups, which Admins can manage in the Vault Admin UI. Learn more in the Vault Help Release Notes
Learn more in the Javadocs
SDK Profiler: Request Summary
Section link for SDK Profiler: Request SummarySDK profiling sessions allow developers to troubleshoot custom solutions and improve code quality by analyzing results at the SDK request level. Developers can create profiling sessions that capture all SDK requests that occur while the session is active. Profiling results can be downloaded using Vault Admin UI and Vault API and include initiating user, execution id, total memory, elapsed time, and cpu time metrics for each request.
Only one profiling session can be active at a time, and a maximum of 10 sessions can be saved. Each session has a maximum duration of 20 minutes and can capture 10,000 SDK requests. Learn more about the SDK Request Profiler in the Vault Java SDK Documentation.
In addition to the Vault Admin UI, developers can list, create, end, delete, and download profiling session data with the newest version of Vault API:
Create Session:
/api/{version}/code/profilerDelete Session:
/api/{version}/code/profiler/{sessionName}Read Session:
/api/{version}/code/profiler/{sessionName}End Session:
/api/{version}/code/profiler/{sessionName}/actions/endList Sessions:
/api/{version}/code/profiler/Download Session CSV:
/api/{version}/code/profiler/{sessionName}/resultsRECENTS & FAVORITES for QueryService
Section link for RECENTS & FAVORITES for QueryServiceWhen creating Custom WebAPIs, developers can execute VQL queries to retrieve the API user's recent and favorite documents and objects. Other custom code that executes as the Java SDK Service account will return 0 results when using RECENTS and FAVORITES.
Object Validation Rule Metadata for SDK
Section link for Object Validation Rule Metadata for SDKDevelopers can now retrieve validation rule metadata for a given object or object type using the ObjectMetadataService with new methods: getObjectValidationRules and getObjectTypeValidationRules. This enables developers to enforce the same validation rules in the UI even if the user is offline.
Learn more in the Javadocs
Disable Audit Trail on User Exception Messages & User Exception Items
Section link for Disable Audit Trail on User Exception Messages & User Exception ItemsRecord changes for the User Exceptions Message and User Exception Item objects are no longer included in audit trails. These objects are used for information purposes to aid in integration management.
Client Credential Support for HTTPService
Section link for Client Credential Support for HTTPServiceVault now allows the creation of Client Credentials (client_crendentials__sys) type records, which can store a Client ID and an encrypted Client Secret. Previously, users could only create Connection Authorization records of the type Basic Authentication (basic_auth__sys). Developers can use these values in the Vault Java SDK together with the HTTPService.
IF EXISTS / IF NOT EXISTS
Section link for IF EXISTS / IF NOT EXISTSMDL now supports two new operators, IF EXISTS and IF NOT EXISTS. Developers and Admins can use these operators to create reusable ALTER MDL scripts that can check Vault configuration and skip processing if the component or subcomponent exists (or not). For example, you can write a script to check if an object field exists and, if so, update the description.
ALTER Object IF EXISTS my_object__c (
Modify Field IF EXISTS comments__c (
description('User Comments')
)
);Required and Read-only Field in Layout Configuration
Section link for Required and Read-only Field in Layout ConfigurationFrom this release, Admins can configure fields on an object page layout to be Required or Read Only, without having to create layout rules. This makes it easier to configure fields that always need to behave in a certain way for a specific page layout.
In the MDL for the Pagelayout component type, the XML for the field within the page_markup attribute now accepts required="true" or readOnly="true". For example:
<vault:field reference="text_field__c" required="true" />
<vault:field reference="text_field__c" readOnly="true" />Tab for Individual Dashboard
Section link for Tab for Individual DashboardThis feature allows customers to create Vault tabs for individual dashboards, which they can associate with Permission Sets. This will let users open a Dashboard as a tab instead of searching for it in the Dashboards Tab. When a new tab is created from the Vault configuration, Admins are presented with a list of dashboards. A dashboard tab cannot be the user's landing tab.
In the MDL, the Component Tab has a new attribute dashboard(), which when set to the API Name of an existing dashboard, turns the component into a Dashboard Tab.
Custom Flash Report Notification
Section link for Custom Flash Report NotificationUsers with permission to schedule flash reports can now customize the email notifications for each flash report. Customizing these messages allows for the inclusion of contextual information, making it easier for recipients to understand what they are receiving, why they are receiving it, and what they need to do. Learn more about the user and admin-facing functionality of this feature in the Vault Help Release Notes
In the MDL for the Flash Report Job, we have added three new attributes that store the custom notification settings:
custom_flash_emailcustom_flash_email_subjectcustom_flash_email_body
Vault Time for Jobs
Section link for Vault Time for JobsWhen scheduling Job Operations, Vault now displays and stores scheduled time in the Vault’s time zone (known as Vault Time). This reduces confusion and improves consistency by ensuring all background operations are using Vault Time. Administrators can change Vault's timezone under Admin > Settings > Language & Region Settings > Vault Information.
In the MDL for Jobs, the timezone attribute will still be accepted for backward compatibility, but will be cleared when editing the component via the UI.
Veeva QMS
Section link for Veeva QMSDeployment Enhancements for Record Check
Section link for Deployment Enhancements for Record CheckTo eliminate the circular dependency between Record Checks and lifecycles when deploying configuration via MDL or VPK, we have introduced a new component and subcomponent type definition: Qualityrecordchecklifecycle and Qualityrelationshipstatemapassociation.
Existing record checks will be migrated to the new components automatically upon release. Vault is still able to handle the old MDL format when creating new Quality Record Checks, but it will display a warning in the API response or VPK deployment log. Updating existing Quality Record Checks with old MDL is not supported. Learn more about the Qualityrecordchecklifecycleassociation components.
Recurrence Check Data Model Changes
Section link for Recurrence Check Data Model ChangesThis release introduces new data model changes to support upcoming capabilities for the Recurrence Check feature. Learn more about the user and admin-facing functionality of this feature in the Vault Help Release Notes
To support these changes, the MDL for the Qualityrecordcheck component type has changed by adding two additional boolean attributes: allow_match_field_overrides and allow_date_overrides.
Reason for Change
Section link for Reason for ChangeTo support the Veeva QMS Reason for ChangeQualityreasonforchange component type was introduced. This component type enables system administrators to configure Veeva QMS to require a reason when changing certain fields on specific object types while a record is in particular lifecycle states.
Learn more about the Qualityreasonforchange components.
Support for Multiple Decision Trees
Section link for Support for Multiple Decision TreesTo support the Multiple Decision Trees featureQualityreportabilitydecisiontreeconfig component type and a new Qualityrdtqualifier subcomponent.
Learn more about the Qualityreportabilitydecisiontreeconfig components type.
Veeva QualityOne
Section link for Veeva QualityOneManage QualityOne Team Assignments
Section link for Manage QualityOne Team AssignmentsWith this release, an API is now available to allow organizations to manage assignments in QualityOne Teams. Prior to this release, Team assignments were supported mainly in the Vault UI, making it necessary to manage assignments and reassignments on a record-by-record basis.
/app/qualityone/qms/teams/vobjects/{object_name}/actions/manageassignmentsThe new bulk-enabled endpoint can add and remove users from Team Roles on records of the {object_name} specified in the endpoint URL.
This feature provides the ability to manage assignments in batches, saving time and ensuring Teams assignments are current.
View this endpoint in the v24.3 API reference.