**Source URL:** https://general.veevavault.dev/rn/25r1.md

# Developer Features in 25R1

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

## 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="25r1">### Java 17 for Vault Java SDK: Auto-Enablement {#java-17-for-vault-java-sdk-auto-enablement}

In 25R2, Veeva is upgrading Vault Java SDK to Java 17. Java 17 includes optimizations that can improve performance and efficiency compared to Java 8, allowing for reduced resource usage.

In this release, Vault is auto-enabling Java 17 compilation in all Vaults. When enabled, Vault compiles new SDK code deployments with Java 17 instead of Java 8. This means that enabling Java 17 does not automatically test your custom code for compatibility, as existing code is not recompiled. To test your code for compatibility with Java 17, redeploy any existing custom code to recompile with Java 17. We are also adding additional Java 17 syntax to the JDK allowlist.

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.

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

In the 25R1 release, we have modified the set of TLS 1.2 cipher suites supported by Vault servers, removing weak cipher suites, and adding support for TLS 1.3. These changes may affect some custom integrations, but not users accessing Vault with a supported browser.
All customers and partners with affected integrations have been contacted directly by Developer Support.

Learn more about [Veeva Vault cipher suite changes](/vault-api/references/tls).

</ReleaseNote>
<ReleaseNote id="OOU0000000MG029" app_family="platform" version="25r1" lr="24r3.2">### Picklist Limit Updates {#OOU0000000MG029}

In multi-value picklist fields on objects, users can select a maximum of 100 values. Prior to this change, users could select more than 1,000 values, which resulted in a less optimal user experience and performance.

To prevent immediate integration interruption, users can still edit existing multi-value picklist fields on object records with more than 100 values selected, as long as the new number of values selected is less than or equal to the quantity currently selected. For example, an existing multi-value picklist with 150 values selected could be updated to 149 selected, but not to 151. Once updated to 149, a subsequent update to the same multi-value picklist could not have 150 values selected.

To ensure the ongoing functionality of integrations, developers need to evaluate their code to ensure all updates to multi-picklist values do exceed 100 picklist values (or the existing number of values, whichever is greater).

Additionally, this feature raises the limit for the number of possible entries that can exist in a picklist (on objects or documents) from 1,204 to 2,000.

</ReleaseNote>

## Release Highlights {#release-highlights}

<ReleaseNote id="OOU0000000OE008" app_family="platform" version="25r1" lr="24r3.2">### Custom Pages {#OOU0000000OE008}

With Custom Pages, your organization can now build completely custom user interfaces in Vault. This enables you to create specialized user interfaces for specific use cases without setting up external infrastructure. For example, with Custom Pages, your organization can build complex data entry forms, aggregated data views, and integration portal interfaces.

Developers create Custom Pages with client-side and server-side code. On the client side, developers write Custom Pages in JavaScript with their preferred frameworks and libraries. On the server side, developers can leverage the power of Vault Java SDK to retrieve and manage Vault data. Integrations can also dynamically send users to Custom Pages within an integration flow.

To create a Custom Page, developers need to:

* **Develop client and server code**: Develop client code with JavaScript and optional server code with Java.

* **Deploy code to Vault**: Deploy server code using [Vault Java SDK Maven plugin](https://github.com/veeva/vaultjavasdk-maven-plugin) and deploy client code using [Vault API](/vault-api/api-reference/25.1/custom-pages).

* **Configure the Custom Page in Vault**: To create a Custom Page, configure a `Page` component. This links the client code and server code in Vault. Custom Pages are secured with permission sets. Your code will run when a user loads the Custom Page. You can also configure a `Tab` or a `Pagelink` component to display a Custom Page in Vault.

Learn more about [Custom Pages](/custom-pages/).

</ReleaseNote>
<ReleaseNote id="OOU0000000OK057" app_family="platform" version="25r1" lr="25r1.0">### Component Definition Query {#OOU0000000OK057}

The Component Definition Query API enables developers to build simple and scalable configuration tools using Vault API. Queries can be constructed to filter and extract component definitions at high speeds, allowing developers to store the configuration in external source code repositories.

This new API supports queries on Vault component records (`vault_component__v`) and retrieving their MDL  (`mdl_definition__v`)  and JSON definitions  (`json_definition__v`). Developers can also query inbound VPK components (`vault_package_component__v`) for the definitions of inbound package component steps, allowing developers to understand which changes were executed as part of the package.

**Component Definition Query:**

<Endpoint path="/api/{version}/query/components" method="POST"></Endpoint></ReleaseNote>
<ReleaseNote id="OOU0000000MX043" app_family="platform" version="25r1" lr="24r3.2">### Word Formatted Outputs {#OOU0000000MX043}

Word Formatted Outputs is a new feature that allows admins to design formatted outputs using a Microsoft Word file instead of an Adobe XFA PDF file as the input file. 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-25r1/#OOU0000000MX043).

This feature has added the `input_file_type` and `output_format` attributes to the [Formattedoutput](/mdl/component-reference/component-types/formattedoutput) component type’s MDL. Existing `Formattedoutput` components will be migrated to the new model upon release. Vault still accepts any VPKs and MDL components using the old model and converts them to the new model upon deployment.

</ReleaseNote>

## 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 id="OOU0000000O6002" app_family="platform" version="25r1" lr="24r3.2">### Roll-up Fields {#OOU0000000O6002}

Roll-up fields offer a powerful way to aggregate values from child records associated with a parent object via a parent-child object relationship, such as calculated expenses in an expense report. Roll-up fields deliver these calculated values over time without manual effort. Learn more about this feature’s user and Admin-facing functionality in the [Vault Help release notes](https://rn.veevavault.help/en/lr/new-in-25r1/#OOU0000000LQ003).

Previously, this functionality was only available with custom SDK code. If your organization currently utilizes custom SDK code which mimics Roll-up field functionality, we encourage you to take advantage of Roll-up fields instead and deprecate your SDK code solution.
Updates to Roll-up fields on parent records are considered a change on the record. However, Roll-up field updates do not invoke Vault Java SDK triggers.

#### MDL {#mdl}

In MDL, Roll-up fields now include several new attributes: `rollup('true')`, `rollup_relationship_name`, `rollup_source_field`, `rollup_function`, and `rollup_filter_criteria`.

#### Vault API {#vault-api}

You can set Roll-up fields using Record Migration Mode, but they otherwise behave as read-only. When you configure a Roll-up field, Vault calculates its value when an event occurs on the child records associated with it.

Developers can initiate a recalculation for Roll-up fields on a single object and check the status of a recalculation using Vault API. When performing a full recalculation on an object, Vault recalculates all Roll-up fields on the object asynchronously.

[Recalculate Roll-up Fields](/vault-api/api-reference/25.1/vault-objects/roll-up-fields/recalculate-roll-up-fields):

<Endpoint path="/api/{version}/vobjects/{object_name}/actions/recalculaterollups" method="POST"></Endpoint>[Retrieve Roll-up Field Recalculation Status](/vault-api/api-reference/25.1/vault-objects/roll-up-fields/retrieve-roll-up-field-recalculation-status):

<Endpoint path="/api/{version}/vobjects/{object_name}/actions/recalculaterollups" method="GET"></Endpoint>#### Vault Java SDK {#vault-java-sdk}

This release brings the following changes to use the Vault Java SDK for Roll-up fields:

* The `ObjectFieldMetadataType` Enum now includes `ROLLUP` as an option to represent a Roll-up object field.

* The `ObjectRollupFieldType` captures the supported return types for a Roll-up field: `CURRENCY`, `DATE`, `DATETIME`, `NUMBER`, `PERCENT`.

* The `ObjectRollupFieldFunctionType` Enum captures the supported return types for a Roll-up field: `COUNT`, `MAX`, `MIN`, `SUM`.

* The `ObjectRollupFieldExpressionMetadata` interface extends `ExpressionMetadata` and returns any configured filter expressions.

* The `ObjectRollupFieldMetadata` interface provides access to metadata on a given Roll-up field.

</ReleaseNote>
<ReleaseNote id="OOU0000000ND002" app_family="platform" version="25r1" lr="24r3.2">### Enhanced Picklist Administration {#OOU0000000ND002}

As part of this feature, we are introducing additional attributes to the `Picklist` component type’s MDL. The new `system_managed` attribute will indicate that users cannot:

* Change the name of the Picklist

* Add new values

* Edit the public keys

* Delete picklist

However, users may be able to change the labels of the picklist values, activate or inactivate them, and change the sequencing depending on the nature of restrictions placed on system and standard picklists.

As part of this feature, picklist values will now be returned via picklist APIs and SDKs sorted ascendingly based on their designated order (MDL `order` attribute). Picklist values that possess the same order value will be sorted in the order they were configured.

#### Picklist Dependencies {#picklist-dependencies}

Prior to this release, dependencies between picklist values could only be specified on the fields that leverage picklist. Because these dependencies exist on the field (not picklist), there could be differing dependencies between two fields that leverage the same picklist. As part of this release, standard picklists can now have dependencies defined on the picklist, as opposed to the field. 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-25r1/#OOU0000000MC003).

Picklists that have dependencies defined will present a new `controlling_picklist` MDL attribute that details the picklist upon which the current one is dependent. In addition to the controlling picklist attribute on the picklist, the `Picklistentry` subcomponents will contain a new `controlling_entries` MDL multi-value attribute that details which values on the controlling picklist the dependent picklist’s value is dependent upon.

#### Vault API {#vault-api-1}

The [Retrieve All Picklists](/vault-api/api-reference/25.1/picklists/retrieve-all-picklists) endpoint has been enhanced to indicate a picklist is system-managed:

<Endpoint path="/api/{version}/metadata/objects/picklists" method="GET"></Endpoint>The [Retrieve Picklist Values](/vault-api/api-reference/25.1/custom-pages/retrieve-single-client-code-distribution-metadata) endpoint has been enhanced to provide any defined system-managed dependencies:

<Endpoint path="/api/{version}/objects/picklists/:\{picklist_name\}" method="GET"></Endpoint>#### Vault Java SDK {#vault-java-sdk-1}

* The `Picklist` Interface is enhanced to return system-managed information.

* A new `PicklistValueMetadataCollectionRequest.Builder` Interface is created to retrieve picklist value
metadata.

* A new `PicklistValueMetadataCollectionResponse` Interface is created to provide results from an executed `PicklistValueMetadataCollection` request.

* A new `PicklistDependencyMetadataCollectionRequest.Builder` Interface is created to retrieve picklist dependency information.

* A new `PicklistDependencyMetadataCollectionResponse` Interface will be created to provide results from an executed `PicklistDependencyMetadataCollectionRequest`.

* A new `PicklistDependency` Interface is created to return picklist dependency information.

</ReleaseNote>

## Vault API v25.1 {#vault-api-v251}

Vault API features added in 25R1 only affect API v25.1, unless otherwise noted.

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

<ReleaseNote id="OOU0000000NC001" app_family="platform" version="25r1" lr="24r3.2">#### SDK Debug Log API {#OOU0000000NC001}

These new endpoints allow developers to manage the SDK Debug Logs via Vault API, which can be used by external tools or to download the files without accessing the UI.

**[Retrieve All Debug Logs](/vault-api/api-reference/25.1/logs/sdk-debug-log/retrieve-all-debug-logs)**:

<Endpoint path="/api/{version}/logs/code/debug" method="GET"></Endpoint>**[Retrieve Single Debug Log](/vault-api/api-reference/25.1/logs/sdk-debug-log/retrieve-single-debug-log)**:

<Endpoint path="/api/{version}/logs/code/debug/{id\}" method="GET"></Endpoint>**[Download Debug Log Files](/vault-api/api-reference/25.1/logs/sdk-debug-log/download-debug-log-files)**:

<Endpoint path="/api/{version}/logs/code/debug/{id}/files" method="GET"></Endpoint>**[Create Debug Log](/vault-api/api-reference/25.1/logs/sdk-debug-log/create-debug-log)**:

<Endpoint path="/api/{version}/logs/code/debug/" method="POST"></Endpoint>**[Reset Debug Log](/vault-api/api-reference/25.1/logs/sdk-debug-log/reset-debug-log)**:

<Endpoint path="/api/{version}/logs/code/debug/{id}/actions/reset" method="POST"></Endpoint>**[Delete Debug Log](/vault-api/api-reference/25.1/logs/sdk-debug-log/delete-debug-log)**:

<Endpoint path="/api/{version}/logs/code/debug/{id\}" method="DELETE"></Endpoint></ReleaseNote>

### Existing Platform Endpoints {#existing-platform-endpoints}

<ReleaseNote id="OOU0000000OB033" app_family="platform" version="25r1" lr="24r3.4">#### Document Template Conversion Enhancements {#OOU0000000OB033}

Vault API now supports converting a basic document template into a controlled document template by specifying the `template_doc_id__v`, which automatically changes the value of the `is_controlled__v` attribute to `true`. These changes apply to the following existing endpoints:

**[Update Single Document Template](/vault-api/api-reference/25.1/documents/document-templates/update-single-document-template)**:

<Endpoint path="/api/{version}/objects/documents/templates/{template_name}" method="PUT"></Endpoint>**[Update Multiple Document Templates](/vault-api/api-reference/25.1/documents/document-templates/update-multiple-document-templates)**:

<Endpoint path="/api/{version}/objects/documents/templates" method="PUT"></Endpoint></ReleaseNote>
<ReleaseNote id="OOU0000000MO015" app_family="platform" version="25r1" lr="24r3.2">#### Optimizing Validate Session User API {#OOU0000000MO015}

To optimize the performance of the [Validate Session User API](/vault-api/api-reference/25.1/users/validate-session-user), starting in v25.1 the response only includes attributes stored in Vault. For example, the endpoint no longer returns the domain name and domain status. Previous versions of the API are unaffected by this change, but developers are encouraged to use the Session Keep-Alive API to keep sessions active and to upgrade to v25.1 to optimize performance when session user information is required.

</ReleaseNote>
<ReleaseNote id="OOU0000000NK012" app_family="platform" version="25r1" lr="24r3.2">#### Document Migration Mode Support for Document Relationships {#OOU0000000NK012}

Document Migration Mode now supports Document Relationships when using Vault Loader (UI and CLI) and Vault API. This feature enhances Vault performance when migrating document relationships in Veeva Promomats.

</ReleaseNote>
<ReleaseNote id="OOU0000000MF029" app_family="platform" version="25r1" lr="24r3.2">#### Migration Package Deployment Enhancements {#OOU0000000MF029}

The [Retrieve Package Deploy Results API](/vault-api/api-reference/25.1/configuration-migration/retrieve-package-deploy-results) now includes a URL to download a ZIP file containing all deployment success and failure logs without needing to access Vault UI.

Additionally, deployment logs are created as record attachment versions on the Vault Package (`vault_package__v`) object. Previously, each log file was a separate attachment. From this release, there is a single attachment, with each new log added a new version.

</ReleaseNote>
<ReleaseNote id="OOU0000000O6030" app_family="platform" version="25r1" lr="24r3.4">#### Audit Grouping ID in Object Audit API {#OOU0000000O6030}

This feature adds the `grouping_id` to the Object Audit API. Vault populates the `grouping_id`, which indicates that the audit entries with the same ID are grouped logically.

</ReleaseNote>

### Application-Specific Endpoints {#application-specific-endpoints}

<ReleaseNote id="OOU0000000O2011" app_family="commercial" version="25r1" lr="24r3.2">#### Vault PromoMats: Deprecating Create Document Update Job API for Standard Metrics {#OOU0000000O2011}

As of this release, we deprecated the Standard Metrics: Create Document Update Job endpoint in all Vault API versions.

</ReleaseNote>
<ReleaseNote id="OOU0000000MW054" app_family="clinical" version="25r1" lr="24r3.2">#### Vault Clinical Operations: Global Procedure Definitions {#OOU0000000MW054}

This feature streamlines procedure management in Vault by allowing for a Vault-level library of global Procedure Definitions that can be used to create Procedure Templates. Learn more about the user and Admin-facing functionality of this feature in the [Vault Help release notes](https://rn.veevavault.help/en/gr/whats-new-in-25r1/#OOU0000000MW054).

With this feature, a [Populate Procedure Definitions](/vault-api/api-reference/25.1/workflows/workflow-tasks) endpoint is now available to create *Procedure Definitions* for a specific study.

<Endpoint path="/api/{version}/app/clinical/ctms/populate-procedure-definitions" method="POST"></Endpoint></ReleaseNote>
<ReleaseNote id="OOU0000000MT019" app_family="clinical" version="25r1" lr="24r3.4">#### Vault Clinical Operations: Merge Global Directory {#OOU0000000MT019}

With this feature, a new endpoint is now available for Clinical Operations Vaults to request the merge of two records on the following Global Directory objects: Person, Contact Information, Organization, and Location. Before records are successfully merged, Vault API performs validation to protect the Global Directory's data integrity. Merging Global Directory data allows for correcting duplicate records that may exist due to migrations, integrations, or day-to-day activities.

[Initiate Clinical Record Merge](/vault-api/api-reference/25.1/workflows/workflow-tasks):

<Endpoint path="/api/{version}/app/clinical/objects/{object_name}/actions/merge" method="POST"></Endpoint></ReleaseNote>
<ReleaseNote id="OOU0000000OF021" app_family="safety" version="25r1" lr="24r3.4">#### Vault Safety Inbox Item Import for Product Quality Complaints {#OOU0000000OF021}

To support the intake of Inbox Items for *Product Quality Complaints*, the [Intake JSON](/vault-api/api-reference/25.1/workflows/workflow-tasks) endpoint now supports the following fields on the Case Adverse Event (`case_adverse_event__v`) object:

* Type (`type__v`)

* Affected Product (`affected_product__v`)

</ReleaseNote>

### OmniConnect JS API {#omniconnect-js-api}

<ReleaseNote id="OOU0000000MS019" app_family="medical" version="25r1" lr="24r3.4">#### Telephony Support: Click to Dial {#OOU0000000MS019}

In MedInquiry Vaults with telephony functionality, users can now dial phone numbers from the *Case* and *Case Contact* pages. To support this in Vaults with custom telephony integrations, we’ve added the following methods to the Omniconnect JS API v25.1:

* `onDial`: Allows the integration to register a function to do the dialing

* `dial`: Accepts a phone number and calls the function assigned in registerDial

* `onDialError`: Accepts a message string that users see in the Vault MedInquiry UI when a call fails to connect

This feature also updates the existing `onConnected` method to accept `isOutbound: true` as part of the `metadata` object.

</ReleaseNote>

## VQL {#vql}

<ReleaseNote id="OOU0000000OB051" app_family="platform" version="25r1" lr="24r3.4">### Order of Operation Support for Parentheses in FIND {#OOU0000000OB051}

Starting in v25.1, the VQL `FIND()` clause respects parentheses and operator precedence. This means that operations enclosed within parentheses are evaluated first, and logical conjunctions (`AND`) take precedence over logical disjunctions (`OR`).

For example, in `FIND ('diabetes' SCOPE ALL AND ('insulin' SCOPE CONTENT OR 'endocrinology' SCOPE PROPERTIES))`, VQL evaluates the operation in parentheses first.

</ReleaseNote>
<ReleaseNote id="OOU0000000MQ030" app_family="platform" version="25r1" lr="24r3.2">### TRIM() Picklist Namespace {#OOU0000000MQ030}

With this release, you can use the new `TRIM()` VQL function with *Picklist* fields in the `SELECT` statement. This function removes the trailing namespace suffix from a picklist value name, such as `__sys`, `__v`, or `__c`. This transforms the query response for picklist names from `picklist_value__c` to `picklist_value`.

</ReleaseNote>
<ReleaseNote id="OOU0000000MQ030" app_family="platform" version="25r1" lr="24r3.2">### Filter by Reference Lookup Field in an Inner Join Subquery {#OOU0000000MQ030}

Vault now supports reference lookups (joins using dot notation) in the `WHERE` clause of an inner join subquery. Developers can leverage this feature to retrieve values from an additional level of separation from the main query.

Example:

```
SELECT id
FROM component__c
WHERE id IN (SELECT parent_component__c FROM sub_components__cr WHERE sub_component_category__cr.name__v = 'VQL')

```
</ReleaseNote>

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

<ReleaseNote id="OOU0000000MT077" app_family="platform" version="25r1" lr="24r3.4">### Workflow Task Action Services SDK {#OOU0000000MT077}

This feature provides Vault Java SDK services to manage workflow tasks. This will enable developers to automate parts of a workflow execution. With the new services and interfaces, developers will be able to access:

* Retrieve Available Workflow Tasks

* Assign Workflow Task

* Cancel Workflow Task

* Reassign Workflow Task

* Unassign Workflow Task

* Update Workflow Task Due Date

Learn more in the [SDK Documentation](/vault-sdk/services/workflow-services/#Workflow_Action_Services).

</ReleaseNote>
<ReleaseNote id="OOU0000000MS072" app_family="platform" version="25r1" lr="24r3.4">### Notification SDK: Send Translated Emails to Persons {#OOU0000000MS072}

Developers can now send translated emails to *Persons* using the Vault Java SDK’s `NotificationService`. To accomplish this, we’ve deprecated the two existing methods for setting notification recipients and replaced them with two new methods. The new methods will accept a `List<String>` instead of a `Set<String>` and will handle duplicate detection automatically:

* `setRecipientsByPersons(List<String>)`: Sends translated emails to *Persons* based on their *Language* field value; consistent with existing behavior to send notifications to Users

* Deprecated: `setRecipientsByPersonIds(Set<String>)`

* `setRecipientsByUsers(List<String>)`: Sends translated emails to *Users* based on their *Language* field value. No behavior change besides `List<String>` instead of a `Set<String>`

* Deprecated: `setRecipientsByUserIds(Set<String>)`

</ReleaseNote>
<ReleaseNote id="OOU0000000OC005" app_family="platform" version="25r1" lr="24r3.4">### Object Metadata SDK: Object Prefix {#OOU0000000OC005}

Developers can now retrieve object metadata by the object prefix using the `.withObjectPrefix()` method. This is useful when trying to determine the metadata for an object based on the object record ID only, as the first three characters of a record ID correspond to the object prefix.

```
ObjectMetadataRequest objectMetadataRequest = 
objectMetadataService.newObjectRequestBuilder()
    .withObjectPrefix("00P") 
    .build();

```
</ReleaseNote>
<ReleaseNote id="OOU0000000NK053" app_family="platform" version="25r1" lr="24r3.2">### Custom Web API: Set Errors {#OOU0000000NK053}

From this release, developers can set the `errors` node of the Custom Web API’s response using the `webApiContext.newWebApiFailureResponseBuilder()`. This allows developers to create response patterns consistent with system and standard Vault APIs.

</ReleaseNote>
<ReleaseNote id="OOU0000000BR009" app_family="platform" version="25r1" lr="24r3.2">### Query Describe for SDK {#OOU0000000BR009}

SDK developers now have access to [Query Describe](/vql/references/vql-api-headers#Query_Describe) metadata when using [Query Service](https://repo.veevavault.com/javadoc/vault-sdk-api/24.3.2/docs/api/com/veeva/vault/sdk/api/query/package-summary.html) to execute and validate VQL queries. Developers can leverage this to understand the data type of the fields returned.

</ReleaseNote>
<ReleaseNote id="OOU0000000NK008" app_family="platform" version="25r1" lr="24r3.2">### Retrieve Picklist with Specified Language {#OOU0000000NK008}

The `PicklistRequest.Builder` is enhanced so that developers can pass a language when constructing their picklist request builder. With this feature, it is now possible to retrieve picklist labels in a specified language, instead of the Vault’s base language or the user’s language.

</ReleaseNote>

## MDL {#mdl-1}

<ReleaseNote id="OOU0000000NP008" app_family="platform" version="25r1" lr="24r3.4">### Email to Vault: Option to Always Run as Email Processor User {#OOU0000000NP008}

For inbound email addresses that allow Persons or Anyone as a sender, Vault Admins now have the option to always use the specified Email Processor User when running the email processor even if the sender’s email address belongs to a Vault User.

To support this, we’ve added the new `run_as_processor_user(boolean)` attribute to the `Inboundemailaddress` component.

</ReleaseNote>
<ReleaseNote id="OOU0000000N3003" app_family="platform" version="25r1" lr="24r3.4">### Summary Email Enhancements and User-Driven Notifications {#OOU0000000N3003}

Vault now includes several enhancements to help reduce notification overload for users by using Summary Email notifications as a standard more frequently. 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-25r1/#OOU0000000N3003).

As part of this feature, the `Notificationtemplate` component MDL now defaults the `email_preferences` attribute to `summary` if no value is specified.

</ReleaseNote>
<ReleaseNote id="OOU0000000NE017" app_family="platform" version="25r1" lr="24r3.4">### Enhanced Formatting Options for Overlay Templates {#OOU0000000NE017}

Admins can now customize page format, adjust font styling, select text alignment, and add logos when creating basic overlay templates that will apply to viewable renditions upon download. Prior to 25R1, Admins needed to leverage XFA templates to apply customizations like these to their overlay templates.

To support this, the MDL for the `Overlaytemplate` component type has additional attributes that store the values for the enhanced options in the component:

* `schema_version` (read-only)

* `header_richtext`

* `signature_block_richtext`

* `footer_richtext`

All existing VPK Packages and MDL will be backward compatible. However, if users view the component in the UI, they will see the new editor window, and upon save, the `Overlaytemplate` component attributes will be stored in the new attributes. Creating new XFA templates is not supported.

</ReleaseNote>
<ReleaseNote id="OOU0000000MC024" app_family="platform" version="25r1" lr="24r3.2">### Enhanced Formatting Options for Signature Page Templates {#OOU0000000MC024}

This feature enables enhanced formatting options, such as the addition of logos or text styling, allowing developers to create signature page templates without Adobe XFA technology.

To support this feature, the `Signaturepage` component has the following new attributes that store the HTML for the appropriate parts of the signature page:

* `header_richtext`

* `signature_block_richtext`

* `footer_richtext`

We’ve also added a new system-managed attribute `schema_version` to MDL to identify whether a `Signaturepage` uses the existing or new enhanced formatting options.

Upon release, existing basic templates will have their Rich Text attributes populated with data translated from existing values in `header_01`, `header_02`, `signature_block_01`, `signature_block_02`, `footer_01`, and `footer_02`, as applicable.

When `schema_version` is `0`, existing attributes `header_01`, `header_02`, `signature_block_01`, `signature_block_02`, `footer_01`, and `footer_02` will be used when generating signature pages using that template. Otherwise, Rich Text attributes will be used.

Any VPKs and MDL using the old header, signature block, and footer attributes will still be accepted. When `schema_version` is `0`, richtext fields will be auto-populated with data translated from those fields upon execution. The same applies if `schema_version` is not `0` as long as no value is provided in the corresponding Rich Text attribute.

</ReleaseNote>

### Application-Specific MDL {#application-specific-mdl}

<ReleaseNote id="OOU0000000MZ027" app_family="quality" version="25r1" lr="24r3.2">#### Veeva Quality: Deployment Enhancements for Quality Teams {#OOU0000000MZ027}

A circular dependency between Quality Teams and formatted outputs when deploying configuration using a VPK has been resolved by introducing a new component and subcomponent: `Qualityteamlifecycleassociation` and `Qualityteamrolelifecycleassociation`. Existing Quality Teams will be migrated to the new components automatically upon release.

</ReleaseNote>
<ReleaseNote id="OOU0000000MS102" app_family="quality" version="25r1" lr="24r3.4">#### Veeva Quality: Create Related Record: Copy Related Object Data {#OOU0000000MS102}

In Quality Vaults, *Related Record Configurations* now include a new section that defines reference records to be copied when the *Create Related Record* action executes, greatly reducing time spent doing manual data entry.

To support this feature, the `Relatedrecordsetup` MDL component type now includes the `copy_attachments` attribute and the new `Relatedrecordreferencemapping` subcomponent type.

</ReleaseNote>
<ReleaseNote id="OOU0000000NN010" app_family="quality" version="25r1" lr="24r3.4">#### Veeva QMS: Reason for Change: Support for Custom Objects {#OOU0000000NN010}

Admins can now configure the *Reason for Change* feature for custom objects. To support this feature, the `Qualityreasonforchange` component MDL has the following new attributes:

* `capture_field` (Subcomponent)

* `capture_type_field` (Subcomponent)

* `record_trigger` (Component Reference)

</ReleaseNote>
<ReleaseNote id="OOU0000000MT095" app_family="platform" version="25r1" lr="24r3.4">#### Veeva QMS: Quality Event Suggestions {#OOU0000000MT095}

To support this feature, the `Qualityrecordcheck` component’s `display_fields` attribute is now conditional. This means that if the `Qualityrecordcheck` is for *Quality Event Suggestions*, `display_fields` aren’t required, but they will remain required for recurrence checks and duplicate checks.
In addition, two additional subcomponents have been introduced to capture the field and related record suggestions configuration: `Qualityfieldsuggestion` and `Qualityrelatedrecordsuggestion`.

</ReleaseNote>