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.
Over the next several releases, Veeva is upgrading the Vault Java SDK to Java 17 to allow developers to take advantage of the upgrades that come with the new version. 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.
Release Dates:
Release Date: August 23, 2024
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.
Yes/No fields using the Show as checkbox option now support null values. This means checkbox fields now 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.
For example, 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 API and SDK would return false for checkboxes saved with no value. With this feature, checkboxes without values will save as null, and return null from the API and SDK.
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.
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 are a new field type in Vault that allows 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.
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.
REST API features added in 24R3 only affect API v24.3, unless otherwise noted.
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
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
POST /api/{version}/services/configuration_mode/actions/disable
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.
Record changes for the User Exceptions Message (UEM) and User Exception Item (UEI) objects are no longer included in audit trails. These objects are used for information purposes to aid in integration management.
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.
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.
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')
)
);
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.
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.
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
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.
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.