Developer Features in 24R3

We are pleased to bring you the following additions and enhancements to Developer Portal features in 24R3.

Service Announcements

Service 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

Release Date: 24R2.3; September 27, 2024

See Full Release Schedule

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.

TLS Cipher Suite and Version Changes

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:

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

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.

Vault Loader CLI Java 17 Support

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.

Yes/No Checkbox Field Enhancement

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.

Migrate Document Usage Object to Raw Object

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.

Attachment Fields

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.

Field Subtypes

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.

Object Type Descriptions

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.

Workflow Participants: User Reference Fields, User Groups, and Task Prompts

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.

Persistent ID for Annotations

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.

Report Configuration Migration Enhancements

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" />

REST API v24.3

Vault REST API features added in 24R3 only affect API v24.3, unless otherwise noted.

Global REST API Changes

Global REST API changes are features that affect the Vault REST API holistically rather than specific endpoints. For example, changes to API burst limits.

Record Migration Mode Enhancements

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.

New Platform Endpoints

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.

Configuration Migration Mode API

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.

Existing Platform Endpoints

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.

Direct Data API - Workflow Support

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:

Legacy workflows:

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

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:

Create Single Document API: Enforce Document Template Limits

Release 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.

Archive Notifications after Three Months

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.

Support Creating 500 GB Documents via API

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:

Name Support in Documents APIs

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:

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:

Vault Safety

Faster Intake Integrations with JSON API

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.

Deprecate the Receive E2B API Endpoint

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.

MedInquiry: Telephony Support

Telephony Support: Conversations

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.

VQL

VQL Date Literals

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.

Strict Matching Adjustments

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.

Vault Java SDK

Java SDK Debugger Dependency

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>

Custom Web API

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.

SDK Profiler: Request Summary

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

RECENTS & FAVORITES for QueryService

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.

Object Validation Rule Metadata for SDK

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.

Disable Audit Trail on User Exception Messages & User Exception Items

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.

Client Credential Support for HTTPService

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.

MDL

IF EXISTS / IF NOT EXISTS

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')
    )
);

Required and Read-only Field in Layout Configuration

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" />

Tab for Individual Dashboard

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.

Custom Flash Report Notification

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:

Vault Time for Jobs

Release 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.

Vault QMS

Deployment Enhancements for Record Check

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.

Recurrence Check Data Model Changes

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.

Reason for Change

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.

Support for Multiple Decision Trees

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.

Vault QualityOne

Manage QualityOne Team Assignments

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.