**Source URL:** https://limited.veevavault.dev/rn/24r3.md

# 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}

Service Announcements are changes that may affect existing integrations. Organizations should assess these features against their existing integrations and make updates where necessary.

<ReleaseNote id="OOU0000000LL015" app_family="platform" version="24r3" lr="24r2.3">### Java 17 for Vault Java SDK: Optional Enablement {#OOU0000000LL015}

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.

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.

</ReleaseNote>
<ReleaseNote id="OOU0000000MQ001" app_family="platform" version="24r3" lr="24r3.2">### TLS Cipher Suite and Version Changes {#OOU0000000MQ001}

Beginning with the 25R1 release, Vault will add support for TLS 1.3 and no longer support CBC cipher suites:

* `ECDHE-RSA-AES256-SHA384`

* `ECDHE-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](/vault-api/references/tls).

## Global Changes {#global-changes}

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

</ReleaseNote>
<ReleaseNote id="OOU0000000LZ015" app_family="platform" version="24r3" lr="24r2.2">### Vault Loader CLI Java 17 Support {#OOU0000000LZ015}

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.

</ReleaseNote>
<ReleaseNote id="OOU0000000LC036" app_family="platform" version="24r3" lr="24r2.2">### Yes/No Checkbox Field Enhancement {#OOU0000000LC036}

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](https://rn.veevavault.help/en/lr/new-in-24r3/#OOU0000000LC036).

</ReleaseNote>
<ReleaseNote id="OOU0000000IH028" app_family="platform" version="24r3" lr="24r2.2">### Migrate Document Usage Object to Raw Object {#OOU0000000IH028}

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](https://platform.veevavault.help/en/gr/42968).

</ReleaseNote>
<ReleaseNote id="OOU0000000MF035" app_family="platform" version="24r3" lr="24r2.2">### Attachment Fields {#OOU0000000MF035}

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](https://repo.veevavault.com/javadoc/vault-sdk-api/24.2.4/docs/api/com/veeva/vault/sdk/api/data/package-summary.html).

Learn more about [attachment fields in Vault Help](https://platform.veevavault.help/en/gr/15057/#attachment-fields). Learn more about the [API endpoints](/vault-api/api-reference/24.3/vault-objects/attachment-fields) and [VQL functions](/vql/functions-options/attachment-field-functions) for working with attachment fields.

</ReleaseNote>
<ReleaseNote id="OOU0000000MF036" app_family="platform" version="24r3" lr="24r2.3">### Field Subtypes {#OOU0000000MF036}

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](https://rn.veevavault.help/en/lr/new-in-24r3/#OOU0000000MF036).

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](/vault-sdk/references/data-type-map).

</ReleaseNote>
<ReleaseNote id="OOU0000000MX012" app_family="platform" version="24r3" lr="24r2.2">### Object Type Descriptions {#OOU0000000MX012}

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.

</ReleaseNote>
<ReleaseNote id="OOU0000000MG001" app_family="platform" version="24r3" lr="24r2.2">### Workflow Participants: User Reference Fields, User Groups, and Task Prompts {#OOU0000000MG001}

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 Vault API and Java SDK. This allows integrations and custom SDK solutions to access and define participant values based on custom business rules.

</ReleaseNote>
<ReleaseNote id="OOU0000000JY076" app_family="platform" version="24r3" lr="24r2.3">### Persistent ID for Annotations {#OOU0000000JY076}

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 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](/vault-sdk/services/annotation-services).

</ReleaseNote>
<ReleaseNote id="OOU0000000M8066" app_family="platform" version="24r3" lr="24r2.3">### Report Configuration Migration Enhancements {#OOU0000000M8066}

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

```
</ReleaseNote>

## Vault API v24.3 {#vault-api-v243}

Vault API features added in 24R3 only affect [API v24.3](/vault-api/api-reference/24.3/workflows/workflow-tasks), unless otherwise noted.

### Global Vault API Changes {#global-vault-api-changes}

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

<ReleaseNote id="OOU0000000LE025" app_family="platform" version="24r3" lr="24r2.4">#### Record Migration Mode Enhancements {#OOU0000000LE025}

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:

* 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](https://platform.veevavault.help/en/gr/761685).

</ReleaseNote>

### New Platform Endpoints {#new-platform-endpoints}

These new endpoints are only available in [API v24.3](/vault-api/api-reference/24.3/workflows/workflow-tasks), unless otherwise noted. To take advantage of these new endpoints, you must use API v24.3.

<ReleaseNote id="OOU0000000MS026" app_family="platform" version="24r3" lr="24r2.2">#### Configuration Migration Mode API {#OOU0000000MS026}

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.

<Endpoint path="/api/{version}/services/configuration_mode/actions/enable" method="POST"></Endpoint>View this endpoint in the [v24.3 Vault API Reference](/vault-api/api-reference/24.3/configuration-migration/enable-configuration-mode).

<Endpoint path="/api/{version}/services/configuration_mode/actions/disable" method="POST"></Endpoint>View this endpoint in the [v24.3 Vault API Reference](/vault-api/api-reference/24.3/configuration-migration/disable-configuration-mode).

</ReleaseNote>

### Existing Platform Endpoints {#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](/vault-api/api-reference/24.3/workflows/workflow-tasks), unless otherwise noted. To take advantage of these new features, you must upgrade your integration’s API version.

<ReleaseNote id="OOU0000000K4028" app_family="platform" version="24r3" lr="24r2.4">#### Direct Data API - Workflow Support {#OOU0000000K4028}

In an effort to further improve the [Direct Data API](/direct-data-api/), with this release, Direct Data files now contain extracts for workflows. This includes legacy workflows, with the following breakdown:

**Workflows**:

* `workflow__sys`

* `workflow_item__sys`

* `workflow_task__sys`

* `workflow_task_item__sys`

**Legacy workflows**:

* `active_legacy_workflow__sys`

* `active_legacy_workflow_task__sys`

* `inactive_legacy_workflow__sys`

* `inactive_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.

</ReleaseNote>
<ReleaseNote id="OOU0000000NB007" app_family="platform" version="24r3" lr="24r2.3">#### Vault Licensing API application_name returns API names {#OOU0000000NB007}

Starting in this release, when obtaining the Licensing information via API,  the [Retrieve Application License Usage API](/vault-api/api-reference/24.3/users/retrieve-application-license-usage) 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`

</ReleaseNote>
<ReleaseNote id="OOU0000000MT052" app_family="platform" version="24r3" lr="24r2.2">#### Create Single Document API: Enforce Document Template Limits {#OOU0000000MT052}

In 24R1, we introduced [Document Template Limits](/rn/24r1/#24r1-document-templates-limit). Starting in 24R2, these limits are also enforced in all versions of the Create Single Document API.

<Endpoint path="/api/{version}/objects/documents" method="POST"></Endpoint></ReleaseNote>
<ReleaseNote id="OOU0000000MY050" app_family="platform" version="24r3" lr="24r2.3">#### Add Annotation ID to Link Target Object {#OOU0000000MY050}

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`), *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](/vault-api/api-reference/24.3/documents/document-annotations) and then use the [Create Object Records API](/vault-api/api-reference/24.3/vault-objects/create-upsert-object-records) 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.

</ReleaseNote>
<ReleaseNote id="OOU0000000MV003" app_family="platform" version="24r3" lr="24r2.3">#### Archive Notifications after Three Months {#OOU0000000MV003}

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](https://rn.veevavault.help/en/lr/new-in-24r3/#OOU0000000MV003).

Starting in API v24.3, requests to the [Retrieve Email Notification Histories API](/vault-api/api-reference/24.3/logs/retrieve-email-notification-histories) 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.

</ReleaseNote>
<ReleaseNote id="OOU0000000MP011" app_family="platform" version="24r3" lr="24r2.2">#### Support Creating 500 GB Documents via API {#OOU0000000MP011}

For all versions of the API, this feature increases the file size limit from 4 GB to 500 GB when using the following endpoints:

* [Create Multiple Documents](/vault-api/api-reference/24.3/documents/create-documents/create-multiple-documents)

* [Create Multiple Document Versions](/vault-api/api-reference/24.3/documents/update-documents/create-multiple-document-versions)

</ReleaseNote>
<ReleaseNote id="OOU0000000NU015" app_family="platform" version="24r3" lr="24r2.2">#### Name Support in Documents APIs {#OOU0000000NU015}

Prior 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](/vault-api/api-reference/24.3/documents/create-documents/create-single-document)

* Create Document from Template

* Create Content Placeholder Document

* Create Unclassified Document

* [Create Multiple Documents](/vault-api/api-reference/24.3/documents/create-documents/create-multiple-documents)

* [Create Multiple Document Versions](/vault-api/api-reference/24.3/documents/update-documents/create-multiple-document-versions)

* [Update Multiple Documents](/vault-api/api-reference/24.3/documents/update-documents/update-multiple-documents) (only when updating picklist values)

* [Create Binders](/vault-api/api-reference/24.3/binders/create-binders)

</ReleaseNote>

### Veeva Safety {#veeva-safety}

<ReleaseNote id="OOU0000000L0014" app_family="safety" version="24r3" lr="24r2.2">#### Faster Intake Integrations with JSON API {#OOU0000000L0014}

Case Narratives and Transmission information, such as origin, can now be ingested using the Intake JSON API:

<Endpoint path="/api/{version}/app/safety/ai/intake" method="POST"></Endpoint>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.

</ReleaseNote>
<ReleaseNote id="OOU0000000L4009" app_family="safety" version="24r3" lr="24r2.2">#### Deprecate the Receive E2B API Endpoint {#OOU0000000L4009}

The Receive E2B API endpoint was replaced several years ago with a [new endpoint](/vault-api/api-reference/24.2/workflows/workflow-tasks) to import Inbox Items from an E2B (R2) or (R3) file containing one or more Individual Case Safety Reports:

<Endpoint path="/api/{version}/app/safety/intake/inbox-item" method="POST"></Endpoint>In this release, the use of the Receive E2B API endpoint is disabled for all Vaults.

</ReleaseNote>

### MedInquiry: Telephony Support {#medinquiry-telephony-support}

<ReleaseNote id="OOU0000000M1045" app_family="medical" version="24r3" lr="24r2.3">#### Telephony Support: Conversations {#OOU0000000M1045}

As 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](https://rn.veevavault.help/en/lr/new-in-24r3/#OOU0000000M1045).

</ReleaseNote>

## VQL {#vql}

<ReleaseNote id="OOU0000000LN010" app_family="platform" version="24r3" lr="24r2.3">### VQL Date Literals {#OOU0000000LN010}

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](/vql/functions-options/date-literals).

</ReleaseNote>
<ReleaseNote id="OOU0000000LK014" app_family="platform" version="24r3" lr="24r2.2">### Strict Matching Adjustments {#OOU0000000LK014}

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](https://platform.veevavault.help/en/gr/61691/#about-strict-matching).

</ReleaseNote>

## Vault Java SDK {#vault-java-sdk}

<ReleaseNote id="OOU0000000NG006" app_family="platform" version="24r3" lr="24r2.3">### Java SDK Debugger Dependency {#OOU0000000NG006}

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>

```
</ReleaseNote>
<ReleaseNote id="OOU0000000HQ001" app_family="platform" version="24r3" lr="24r2.3">### Custom Web API {#OOU0000000HQ001}

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](https://rn.veevavault.help/en/lr/new-in-24r3/#OOU0000000HQ001).

Learn more in the [Javadocs](https://repo.veevavault.com/javadoc/vault-sdk-api/24.2.3/docs/api/com/veeva/vault/sdk/api/executeas/package-summary.html).

</ReleaseNote>
<ReleaseNote id="OOU0000000BT005" app_family="platform" version="24r3" lr="24r2.2">### SDK Profiler: Request Summary {#OOU0000000BT005}

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](/vault-sdk/troubleshooting-runtime-errors/profiler-log).

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:

<Endpoint path="/api/{version}/code/profiler" method="POST"></Endpoint>Delete Session:

<Endpoint path="/api/{version}/code/profiler/{sessionName}" method="DELETE"></Endpoint>Read Session:

<Endpoint path="/api/{version}/code/profiler/{sessionName}" method="GET"></Endpoint>End Session:

<Endpoint path="/api/{version}/code/profiler/{sessionName}/actions/end" method="POST"></Endpoint>List Sessions:

<Endpoint path="/api/{version}/code/profiler/" method="GET"></Endpoint>Download Session CSV:

<Endpoint path="/api/{version}/code/profiler/{sessionName}/results" method="GET"></Endpoint></ReleaseNote>
<ReleaseNote id="OOU0000000MG077" app_family="platform" version="24r3" lr="24r2.3">### RECENTS & FAVORITES for QueryService {#OOU0000000MG077}

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

</ReleaseNote>
<ReleaseNote id="OOU0000000MG096" app_family="platform" version="24r3" lr="24r2.3">### Object Validation Rule Metadata for SDK {#OOU0000000MG096}

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](https://repo.veevavault.com/javadoc/vault-sdk-api/24.2.3/docs/api/com/veeva/vault/sdk/api/data/ObjectMetadataService.html).

</ReleaseNote>
<ReleaseNote id="OOU0000000LX018" app_family="platform" version="24r3" lr="24r2.3">### Disable Audit Trail on User Exception Messages & User Exception Items {#OOU0000000LX018}

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.

</ReleaseNote>
<ReleaseNote id="OOU0000000MF102" app_family="platform" version="24r3" lr="24r2.2">#### Client Credential Support for HTTPService {#OOU0000000MF102}

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

</ReleaseNote>

## MDL {#mdl}

<ReleaseNote id="OOU0000000MF100" app_family="platform" version="24r3" lr="24r2.2">### IF EXISTS / IF NOT EXISTS {#OOU0000000MF100}

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

```
</ReleaseNote>
<ReleaseNote id="OOU0000000MF121" app_family="platform" version="24r3" lr="24r2.3">### Required and Read-only Field in Layout Configuration {#OOU0000000MF121}

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

```
</ReleaseNote>
<ReleaseNote id="OOU0000000M8050" app_family="platform" version="24r3" lr="24r2.3">### Tab for Individual Dashboard {#OOU0000000M8050}

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.

</ReleaseNote>
<ReleaseNote id="OOU0000000JV032" app_family="platform" version="24r3" lr="24r2.3">### Custom Flash Report Notification {#OOU0000000JV032}

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](https://rn.veevavault.help/en/lr/new-in-24r3/#OOU0000000JV032).

In the MDL for the Flash Report Job, we have added three new attributes that store the custom notification settings:

* `custom_flash_email`

* `custom_flash_email_subject`

* `custom_flash_email_body`

</ReleaseNote>
<ReleaseNote id="OOU0000000MC027" app_family="platform" version="24r3" lr="24r2.3">### Vault Time for Jobs {#OOU0000000MC027}

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.

</ReleaseNote>

## Veeva QMS {#veeva-qms}

<ReleaseNote id="OOU0000000MZ024" app_family="quality" version="24r3" lr="24r2.3">### Deployment Enhancements for Record Check {#OOU0000000MZ024}

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](/mdl/component-reference/component-types/qualityrecordchecklifecycleassociation).

</ReleaseNote>
<ReleaseNote id="OOU0000000NG002" app_family="quality" version="24r3" lr="24r2.3">### Recurrence Check Data Model Changes {#OOU0000000NG002}

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](https://rn.veevavault.help/en/lr/new-in-24r3/#OOU0000000NG002).

To support these changes, the MDL for the [`Qualityrecordcheck` component type](/mdl/component-reference/component-types/qualityrecordcheck) has changed by adding two additional boolean attributes: `allow_match_field_overrides` and `allow_date_overrides`.

</ReleaseNote>
<ReleaseNote id="OOU0000000LJ001" app_family="quality" version="24r3" lr="24r2.3">### Reason for Change {#OOU0000000LJ001}

To support the Veeva QMS [Reason for Change](https://rn.veevavault.help/en/lr/new-in-24r3/#OOU0000000LJ001) feature, a new `Qualityreasonforchange` 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](/mdl/component-reference/component-types/qualityreasonforchange).

</ReleaseNote>
<ReleaseNote id="OOU0000000K3002" app_family="quality" version="24r3" lr="24r2.3">### Support for Multiple Decision Trees {#OOU0000000K3002}

To support the [Multiple Decision Trees feature](https://rn.veevavault.help/en/lr/new-in-24r3/#OOU0000000K3002) in QMS & Veeva Product Surveillance-enabled Quality Vaults, there is a new `Qualityreportabilitydecisiontreeconfig` component type and a new `Qualityrdtqualifier` subcomponent.

Learn more about the [Qualityreportabilitydecisiontreeconfig components](/mdl/component-reference/component-types/qualityreportabilitydecisiontreeconfig) type.

## Veeva QualityOne {#veeva-qualityone}

</ReleaseNote>
<ReleaseNote id="OOU0000000MH008" app_family="qualityone" version="24r3" lr="24r2.3">### Manage QualityOne Team Assignments {#OOU0000000MH008}

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.

<Endpoint path="/app/qualityone/qms/teams/vobjects/{object_name}/actions/manageassignments" method="POST"></Endpoint>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](/vault-api/api-reference/24.3/workflows/workflow-tasks).

</ReleaseNote>