We are pleased to bring you the following additions and enhancements to Developer Portal features in 24R3.
Service Announcements are changes that may affect existing integrations. Organizations should assess these features against their existing integrations and make updates where necessary.
Release Date: 24R2.3; September 27, 2024
Over 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. Learn how to enable Java 17 in your Vault.
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 13, 2024
Beginning 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-SHA256These 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 are features that affect multiple product areas or affect Vault holistically. For example, new functionality accessible through both the Vault REST API and the Vault Java SDK.
Release Date: 24R2.2; August 23, 2024
In 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.
Release Date: 24R2.2; August 23, 2024
Yes/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.
Release Date: 24R2.2; August 23, 2024
The 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.
Release Date: 24R2.2; August 23, 2024
Attachment 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. Learn more about the API endpoints and VQL functions for working with attachment fields.
Release Date: 24R2.3; September 27, 2024
Field 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.
Release Date: 24R2.2; August 23, 2024
Admin 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.
Release Date: 24R2.2; August 23, 2024
Workflow 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 the Vault REST API and Java SDK. This allows integrations and custom SDK solutions to access and define participant values based on custom business rules.
Release Date: 24R2.3; September 27, 2024
Vault 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 REST APIs. It is added to new and updated annotations when creating and editing them in the REST API.
Learn more about working with annotations in the Vault Java SDK.
Release Date: 24R2.3; September 27, 2024
This 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 REST API features added in 24R3 only affect API v24.3, unless otherwise noted.
Global REST API changes are features that affect the Vault REST API holistically rather than specific endpoints. For example, changes to API burst limits.
Release Date: 24R2.4; October 18, 2024
To 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:
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.
These 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.
Release Date: 24R2.2; August 23, 2024
To 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.
POST /api/{version}/services/configuration_mode/actions/enable
View this endpoint in the v24.3 REST API Reference.
POST /api/{version}/services/configuration_mode/actions/disable
View this endpoint in the v24.3 REST API Reference.
In 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.
Release Date: 24R2.4; October 18, 2024
In 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__sysLegacy workflows:
active_legacy_workflow__sysactive_legacy_workflow_task__sysinactive_legacy_workflow__sysinactive_legacy_workflow_task__sysWith 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.
Release Date: 24R2.3; September 27, 2024
Starting 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:
pmPromoMats_vpm_promomats__vRelease Date: 24R2.2; August 23, 2024
In 24R1, we introduced Document Template Limits. Starting in 24R2, these limits are also enforced in all versions of the Create Single Document API.
POST /api/{version}/objects/documents
Release Date: 24R2.3; September 27, 2024
Vault 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).
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.
Release Date: 24R2.3; September 27, 2024
Notifications 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.
Release Date: 24R2.2; August 23, 2024
For all versions of the API, this feature increases the file size limit from 4 GB to 500 GB when using the following endpoints:
Release Date: 24R2.2; August 23, 2024
Prior to this release, the Vault REST 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:
type__v)subtype__v)classification__v)lifecycle__v)status__v)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:
Release Date: 24R2.2; August 23, 2024
Case Narratives and Transmission information, such as origin, can now be ingested using the Intake JSON API:
POST /api/{version}/app/safety/ai/intake
Developers 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.
Release Date: 24R2.2; August 23, 2024
The 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:
POST /api/{version}/app/safety/intake/inbox-item
In this release, the use of the Receive E2B API endpoint is disabled for all Vaults.
Release Date: 24R2.3; September 27, 2024
As part of Vault 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.
Release Date: 24R2.3; September 27, 2024
VQL 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.
Release Date: 24R2.2; August 23, 2024
When 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.
Release Date: 24R2.3; September 27, 2024
Developers 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>
Release Date: 24R2.3; September 27, 2024
Developers 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.
Release Date: 24R2.2; August 23, 2024
SDK 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 the Vault REST API:
Create Session:
POST /api/{version}/code/profiler
Delete Session:
DELETE /api/{version}/code/profiler/{sessionName}
Read Session:
GET /api/{version}/code/profiler/{sessionName}
End Session:
POST /api/{version}/code/profiler/{sessionName}/actions/end
List Sessions:
GET /api/{version}/code/profiler/
Download Session CSV:
GET /api/{version}/code/profiler/{sessionName}/results
Release Date: 24R2.3; September 27, 2024
When 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.
Release Date: 24R2.3; September 27, 2024
Developers 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.
Release Date: 24R2.3; September 27, 2024
Record 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.
Release Date: 24R2.2; August 23, 2024
Vault 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.
Release Date: 24R2.2; August 23, 2024
MDL 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')
)
);
Release Date: 24R2.3; September 27, 2024
From 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" />
Release Date: 24R2.3; September 27, 2024
This 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.
Release Date: 24R2.3; September 27, 2024
Users 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_bodyRelease Date: 24R2.3; September 27, 2024
When 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.
Release Date: 24R2.3; September 27, 2024
To 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.
Release Date: 24R2.3; September 27, 2024
This 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.
Release Date: 24R2.3; September 27, 2024
To support the Vault QMS Reason for Change feature, a new Qualityreasonforchange component type was introduced. This component type enables system administrators to configure Vault 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.
Release Date: 24R2.3; September 27, 2024
To support the Multiple Decision Trees feature in QMS & Vault Product Surveillance-enabled Quality Vaults, there is a new Qualityreportabilitydecisiontreeconfig component type and a new Qualityrdtqualifier subcomponent.
Learn more about the Qualityreportabilitydecisiontreeconfig components type.
Release Date: 24R2.3; September 27, 2024
With 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.
POST /app/qualityone/qms/teams/vobjects/{object_name}/actions/manageassignments
The 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.