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. 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: 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.
Release Date: 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.
As an additional enhancement to the Record Migration Mode Enhancements released in 24R2.3, Record Migration mode now allows migrators to bypass picklist dependencies, set object type and document references to inactive values, and change the object type of Records. Additionally, Record Migration Mode now includes support for user__sys.
Release Date: September 27, 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.
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.
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. Although the Persistent ID is settable when creating annotations via the API, we do not recommend doing so because overriding the system-provided value invalidates the uniqueness constraint and traceability provided by the standard format.
Learn more about working with annotations in the Vault Java SDK.
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.
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" />
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.
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_bodyAs 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. Vault provides a standard integration to Amazon Connect. Other CTIs 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.
REST API features added in 24R3 only affect API v24.3, unless otherwise noted.
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, the system allows setting system fields (ID, Created By, Created Date, Modified By, Modified Date) and bypasses all rules except:
The User object (user__sys) does not support enhanced migration mode. This means required fields are still enforced, triggers will execute, and system managed fields are read-only.
We have 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 headers.
Learn more about Record Migration Mode in Vault Help.
When using Vault Loader, users can take advantage of the enhancements made to Record Migration Mode. Users must have Migration Mode permissions to use the headers. Learn more about the user and admin-facing functionality of this feature in the Vault Help Release Notes.
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, the Retrieve Email Notification Histories API will return up to three months of notifications compared to the prior limit of two years.
Starting in this release, when obtaining the Licensing information via API, it will return the API Name instead of the legacy values:
pmPromoMats_vpm_promomats__vView this endpoint in the v24.3 API Reference.
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.
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>
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.
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.
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.
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.
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" />
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.
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: Qualityrecordcheckstateassociation and Qualityrecordcheckincludedstate.
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 Record Checks, but it will display a warning in the API response or VPK deployment log. Updating existing Record Checks with old MDL is not supported.
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.
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 component type.
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 component type.
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.
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.
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.