**Source URL:** https://general.veevavault.dev/rn/26r2

# Developer Features in 26R2

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

## 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="OOU0000000QX028" lr="26r1.2" app_family="platform" version="26r2">
### Global API Header Changes

We are making the following changes to all Vault API versions starting with the 26R1.2 release:

*   **Status Line**: Vault API will return a numeric-only status line. For example, `HTTP/1.1 200` instead of `HTTP/1.1 200 OK`. Integration logic must be updated to validate responses based on the numeric status code (integer) rather than searching for descriptive text strings like "OK." Per RFC 9112, the reason phrase is optional and deprecated in modern protocols.
*   **Cache-Control**: Vault API will no longer return the `Expires` header. Integrations should use the explicit `Cache-Control: no-store, no-cache` directives. Legacy clients that previously relied on the 1970 epoch date for cache invalidation must be updated to recognize modern Cache-Control headers. This ensures consistent data privacy across modern CDNs and browsers.
*   **Vary**: The header "Vary: Accept-Encoding" will be transmitted in lowercase format "vary: accept-encoding" to comply with HTTP/2 and HTTP/3 standards.
</ReleaseNote>

<ReleaseNote id="OOU0000000R5008" lr="26r1.2" app_family="platform" version="26r2">
### Support ExecuteAs for Documentaction

Added `@ExecuteAs` support for `DocumentAction` entry points.

Additionally, `DocumentActionContext.getDocumentVersions()` now defaults to *Java SDK Service Account* instead of the Request Owner. Please review your implementations to ensure this shift in default permissions aligns with your security requirements:

*   **26R1 Behaviour**: `getDocumentVersions()` runs as Request Owner by default
*   **26R2 Behaviour**: `getDocumentVersions()` runs as System by default
</ReleaseNote>

<ReleaseNote id="OOU0000000RP011" lr="26r1.3" app_family="platform" version="26r2">
### SDK HttpService no longer supports TLS v1 and v1.1

With this release, we no longer support the TLS v1 and v1.1 insecure protocols and ciphersuites.
</ReleaseNote>

<ReleaseNote id="OOU0000000K6006" lr="26r1.3" app_family="platform" version="26r2">
### NotificationService SDK Enhancements

We are changing the way notifications can be sent to users via Vault Java SDK using `NotificationService`. We are introducing the following new interfaces:

*   `NotificationQueueRequest` represents a request to queue a notification for delivery
*   `NotificationQueueMessage` defines the content of a notification
*   `NotificationQueueOperation` the event handler
*   `NotificationQueueResponse` represents the response of a notification queue request
*   `NotificationQueueOperationError` represents an error that occurred during a notification queueing operation
    *   `NotificationQueueOperationErrorType` enum defines categories of errors for queueing a notification
*   `NotificationLanguageContext` provides context for resolving localized language tokens for a notification
*   `NotificationLanguageResponse` represents the localized token mappings for specific languages

The following interfaces or methods using these will be deprecated:

*   `NotificationMessage`
*   `NotificationTemplate`
*   `NotificationParameters`
</ReleaseNote>

<ReleaseNote id="MCP_Announcement" lr="26r1.3" app_family="platform" version="26r2">
### Vault Docs MCP

As of June 8th, 2026, the Vault Developer Docs MCP is now the Vault Docs MCP. This name change reflects the addition of the **search\_vault\_help\_docs** tool, which allows LLM clients to directly access Platform Vault Help documentation. Existing tools still allow access to the Vault API reference, Vault SDK Javadocs, VAPIL Javadocs, and Vault Developer Portal documentation, providing a full range of Vault expertise from the convenience of your favorite LLM. Learn more about the [Vault Docs MCP](/mcp).
</ReleaseNote>

## Release Highlights

<ReleaseNote id="OOU0000000PA040" lr="26r1.3" app_family="platform" version="26r2">
### API Access Tokens

This feature allows you to use a long-lived API access token to authenticate to the Vault API. Using a long-lived token enables integration with tools that expect a static token and lets you replace authentication sub-processes in integrations.

Access tokens do not give Vault UI access, are valid for one specific Vault, and grant the permissions of the user who generated the access token. Each user can have up to 25 active access tokens.

Only users who have API permission can create access tokens. The maximum access token expiry duration is set in the user's security policy.
</ReleaseNote>

## Vault AI

<ReleaseNote id="OOU0000000R6055" lr="26r1.3" app_family="platform" version="26r2">
### API Access Control for Agent Actions

This feature introduces a new agent action attribute, *API Access* (`api_access`), that controls whether an agent action is visible to the MCP server and Vault API. If set to `false`, no call to Vault API or MCP server can be made to the agent action.
</ReleaseNote>

<ReleaseNote id="OOU0000000QI001" lr="26r1.4" app_family="platform" version="26r2">
### MCP Server

Vault MCP Server allows client AI apps to invoke agent actions with *API Access* set to *true*.

Client apps can be other chat clients such as Claude, Gemini, and Copilot, or they can be agents that call Vault agents to perform a task.

Vault MCP Server requires an access token to initiate a session from the client. It does not support OAuth 2.0 and basic authentication. Each access token uniquely identifies a user in a specific Vault. The user's permissions are used to control which agent actions are available to the client.

Vault MCP Server supports Streamable HTTP via a single endpoint: `/api/ai/mcp`
</ReleaseNote>

<ReleaseNote id="OOU0000000RT017" lr="26r1.4" app_family="platform" version="26r2">
### Vault AI UI Minor Update

The Vault user interface now refers to Vault AI instead of Veeva AI.
</ReleaseNote>

<ReleaseNote id="OOU0000000R5028" lr="26r1.2" app_family="platform" version="26r2">
### JSON Response Tool Type

Vault AI introduces the JSON Response tool type, allowing Admins to configure an agent action that generates structured JSON output.

This ensures the agent action returns its output in a consistent, predictable format that can be consumed programmatically via the Vault API or Vault Java SDK.
</ReleaseNote>

## VQL

<ReleaseNote id="OOU0000000NV012" lr="26r1.2" app_family="platform" version="26r2">
### Query Profiler

This feature allows Admins and Developers to monitor VQL query performance with the new query profiling tool. Analysing the profile of queries is a key part in monitoring their performance and overall health, but previously this process has been challenging.

Now with Query Profiler, the results makes it easy to analyse the queries running in Vault, by looking at the data obtained during a profiling session. Users will need to start a profiling session where they will also be able to set filters on what kind of VQL queries should be included in the results. These filters include:

*   **Origin**: filters where the VQL query originated from (API, SDK, or ALL)
*   **Targets**: filters the specific Query Targets of the VQL query (e.g.: restricting to queries on `user__sys`)
*   **Result Count**: filters queries to only be included if their result count is in a Min / Max range
*   **Query Time**: filters queries to only be included if their execution time is in a Min / Max range
*   **Response Status**: filters whether the query was a SUCCESS, FAILURE or if it received a WARNING
</ReleaseNote>

<ReleaseNote id="OOU0000000LE030" lr="26r1.2" app_family="platform" version="26r2">
### Hierarchy: VQL Relationship

A new VQL relationship for hierarchy nodes allows Admins and Developers to see the ordering of hierarchical objects like EDL and EDL Item. Previously the order for these types of object records was only visible in the hierarchy viewer UI.
</ReleaseNote>

<ReleaseNote id="OOU0000000BP015" lr="26r1.3" app_family="platform" version="26r2">
### Object Record Roles for VQL

Users can now run queries on object record roles. This functionality is available as a subquery, meaning you can query object record roles as related data with the Vault object as the primary query target.

The query supports role assignments granted via the following mechanisms:

*   Manual Assignment
*   Custom Sharing Rules
*   Matching Sharing Rules
*   Child Security (where parent's security is supported)

```sql
SELECT id, name__v, 
  (SELECT role_name__sys, user__sys, assignment_type__sys FROM roles__sysr) 
FROM product__v 
WHERE id = 'V0B000000003009'
```
</ReleaseNote>

<ReleaseNote id="OOU0000000P9087" lr="26r1.3" app_family="platform" version="26r2">
### Retrieve Document Properties in VQL

Users can now retrieve document permissions and field editability information when executing VQL queries by including the `X-VaultAPI-DocumentProperties` header, enabling more efficient permission checking for document operations. This brings documents closer together with objects that already had the `X-VaultAPI-RecordProperties` header available.
</ReleaseNote>

## Vault Java SDK

<ReleaseNote id="OOU0000000NM028" lr="26r1.2" app_family="platform" version="26r2">
### Support Paging for QueryService

This feature allows pagination when running VQL queries in the Vault Java SDK, making it simpler for developers to return results of a specific size.

Previously, the `QueryService` was designed to return a `Stream` of results and explicitly did not support the VQL pagination clauses `PAGESIZE` and `PAGEOFFSET`.

Developers can add `withPageSize(int)` to the Builder, mirroring the VQL query syntax, and we have added new `QueryPaginationResponse` and `QueryPageRequest` interfaces.
</ReleaseNote>

<ReleaseNote id="OOU0000000QD010" lr="26r1.2" app_family="platform" version="26r2">
### RenditionService SDK

Users can now query for information related to the structure of their document and its contained content using `RenditionService`. This includes information about the page count, page sizes, page crop, page rotations, contained bookmarks, and contained named destinations.
</ReleaseNote>

<ReleaseNote id="OOU0000000QG060" lr="26r1.2" app_family="platform" version="26r2">
### Enhancements to SDK DocumentService

A new set of `DocumentService` SDK methods for creating new documents, updating existing document versions, and deleting documents and document versions. New interfaces also add support for updating previous document versions, and creating new versions of documents not in migration mode, which are current gaps in the SDK.

The following new methods are added to the existing `DocumentService` interface:

*   `batchCreateDocuments(DocumentBatchCreateRequest request);`
*   `batchUpdateDocumentVersions(DocumentVersionBatchUpdateRequest request);`
*   `batchDeleteDocuments(DocumentBatchDeleteRequest request);`

The following existing methods will be deprecated from `DocumentService`:

*   `createDocuments(List<DocumentVersion> documentVersions)`
*   `deleteDocumentVersions(List<DocumentVersion> documentVersions)`
*   `saveDocumentVersions(List<DocumentVersion> documentVersions)`
</ReleaseNote>

<ReleaseNote id="OOU0000000QN021" lr="26r1.2" app_family="platform" version="26r2">
### Connection API Name Support for Integration Rule SDK

This enhancement introduces the ability to retrieve integration rules using the Connection API Name rather than strictly requiring the `connectionId`. Using the new `withConnectionName()` method makes the code more portable, easier to read, and it simplifies the use for developers.

```java
// Locate service 
IntegrationRuleService integrationRuleService = 
ServiceLocator.locate(IntegrationRuleService.class); 

// Build request using API Name 
GetIntegrationRulesRequest request = 
integrationRuleService.newGetIntegrationRulesRequestBuilder() 
.withConnectionName("verneo_clinical_conn__c") // Human-readable API Name 
.build();
```
</ReleaseNote>

<ReleaseNote id="OOU0000000QV042" lr="26r1.2" app_family="platform" version="26r2">
### SDK: Workflow Task Metadata & Completion

We are enhancing the `WorkflowTaskService` and `WorkflowMetadataService` to support programmatic workflow task completion. This new functionality allows developers to inspect the requirements (prompts) of a task instance and construct a completion request that satisfies those requirements.

Developers will be able to perform "discovery" to understand what inputs will be required (Task Level, Verdicts, Verdict Reason, Verdict Capacity, etc.) and then perform the "execution" by constructing a completion request.
</ReleaseNote>

<ReleaseNote id="OOU0000000QY038" lr="26r1.2" app_family="platform" version="26r2">
### Doctype Triggers: Add New Version Context Details

Adds new `DocumentTypeCreateDraftExecutionContext` and `DocumentTypeCheckInExecutionContext` interfaces to give doctype trigger developers the ability to differentiate how the new document version was created (Create Draft vs Check-In etc.).
</ReleaseNote>

<ReleaseNote id="OOU0000000MX005" lr="26r1.3" app_family="platform" version="26r2">
### ObjectMetadataService SDK Enhancements

This feature enhances the `ObjectMetadata` and `ObjectFieldMetadata` SDK interface so that all attributes available in our MDL are retrievable in the SDK interface as well. This allows developers to retrieve the complete definition of MDL components.

The following, previously unavailable attributes can now be retrieved from the SDK:

**ObjectMetadata**

*   `description`
*   `help_content`
*   `in_menu`
*   `enable_esignatures`
*   `dynamic_security`
*   `available_lifecycles`
*   `user_role_setup_object`
*   `secure_audit_trail`
*   `secure_sharing_settings`
*   `secure_attachments`
*   `prevent_record_overwrite`
*   `multi_select`
*   `triggers_disallowed`
*   `configuration_data`
*   `enable_merges`
*   `relate_records_select_all`
*   `secure_copy_record`

**ObjectFieldMetadata**

*   `editable`: `isSystemManaged()` returns `true` when `editable` is `false`

**ObjectTextFieldMetadata**

*   `system_managed_name`

**ObjectLookupObjectReferenceFieldMetadata & ObjectLookupParentReferenceFieldMetadata**

*   `relationship_inbound_label`
*   `relationship_inbound_name`
*   `relationship_outbound_name`
*   `object`
*   `relationship_deletion`
</ReleaseNote>

<ReleaseNote id="OOU0000000PX022" lr="26r1.3" app_family="platform" version="26r2">
### Localization Java SDK Service

The `LocalizationService` SDK enables developers to format Date, DateTime, Number, and Currency values according to Vault locale settings. It provides programmatic access to Vault base locale settings, locale metadata (codes and labels for 244 supported locales), and generates formatted display strings from raw base values.
</ReleaseNote>

<ReleaseNote id="OOU0000000QA023" lr="26r1.3" app_family="platform" version="26r2">
### Record Migration Mode Inheritance

When records are created, updated, or deleted in Record Migration Mode, it can cause other records to be created or updated within the same process. In these scenarios, the related records inherit many of the same Record Migration Mode behaviours.

This feature introduces two changes to the current behaviour:

*   In the Object Record Audit History log, "in migration mode" will be added to the description for related records.
*   In the SDK, `isMigrationModeEnabled` will return `true` in the `RecordTriggerContext` for related records.
</ReleaseNote>

<ReleaseNote id="OOU0000000R2013" lr="26r1.3" app_family="platform" version="26r2">
### SDK to Reclassify Documents

This feature adds interfaces to allow reclassifying documents via the Vault Java SDK in bulk, with functional parity with today's existing reclassify behavior. Previously this was only possible by leveraging Vault API.

A new `DocumentService` interface was created to reclassify documents:

*   `batchReclassifyDocuments(DocumentBatchReclassifyRequest request)`
</ReleaseNote>

<ReleaseNote id="OOU0000000R8015" lr="26r1.3" app_family="platform" version="26r2">
### SDK Support for Creating New Document Versions

Developers can now utilize a new method to create new document versions in the SDK, and specify between creating a new draft or uploading a new version.

We have added a new set of `DocumentService` SDK methods for creating, updating, and deleting documents for an improved developer experience. New interfaces also support updating previous document versions, and creating new versions of documents not in migration mode.

The following new methods will be added to the existing `DocumentService` interface:

*   `batchCreateDocuments(DocumentBatchCreateRequest request);`
*   `batchCreateDocumentVersions(DocumentVersionBatchCreateRequest request);`
*   `batchUpdateDocumentVersions(DocumentVersionBatchUpdateRequest request);`
*   `batchDeleteDocuments(DocumentBatchDeleteRequest request);`

The following existing methods will be deprecated from `DocumentService`:

*   `createDocuments(List<DocumentVersion> documentVersions)`
*   `deleteDocumentVersions(List<DocumentVersion> documentVersions)`
*   `saveDocumentVersions(List<DocumentVersion> documentVersions)`
</ReleaseNote>

## Vault API v26.2

<ReleaseNote id="OOU0000000PI096" lr="26r1.3" app_family="platform" version="26r2">
### Hierarchy: Bulk Update Node Order

We are introducing a new API endpoint to give users the ability to update the node order of hierarchical records in bulk, so users no longer need to manually reorder the nodes in the Vault UI.

Hierarchical records are objects that have self-referential parent-child relationships that form a tree, such as *Expected Documents*. Vault Applications may have their own implementations of these hierarchies.

<Endpoint path="/api/{version}/composites/trees/{hierarchyName}/batch" method="PUT" />
</ReleaseNote>

<ReleaseNote id="OOU0000000QH025" lr="26r1.3" app_family="platform" version="26r2">
### Record Migration Mode for Delete Operations

Vault now supports Record Migration Mode for delete operations, along with a *No Triggers* option. This feature allows users to delete migrated records without firing record triggers and action triggers. Blocking references will still prevent record delete operations, even in Record Migration Mode.

This feature is supported for both Vault API and Vault Loader.
</ReleaseNote>

<ReleaseNote id="OOU0000000P9067" lr="26r1.3" app_family="platform" version="26r2">
### Vault Loader Performance Enhancements

Vault Loader jobs now leverage the distributed job framework, which leads to faster load times for Vault datasets.

This means there could be a change in the order in which the datasets are loaded as a later batch may get processed faster than an earlier batch. For example, Batch 3 may get processed faster than Batch 1.

Processes leveraging the sequential loading of records via Vault Loader will need to process the batches of 500 records manually.
</ReleaseNote>

<ReleaseNote id="OOU0000000QX085" lr="26r1.3" app_family="platform" version="26r2">
### Document Inbox Enhancements: Edit Document Type

The Document Inbox has been updated to allow document type classifications to be saved on incomplete documents, documents still in the *Unclassified* lifecycle. Users are now able to save a document type classification on incomplete documents without providing all other required fields for the document type, allowing classification and other information to be populated incrementally when possible. Developers are now able to use the single and bulk Reclassify API endpoints to set just a document type on an incomplete document as well.
</ReleaseNote>

<ReleaseNote id="OOU0000000P7010" lr="26r1.3" app_family="clinical" version="26r2">
### Promote Person to User API

This feature implements an API endpoint that provides the functionality to Promote a Person object record to a User. This was already available on the UI, and now developers can do it via the below API.

<Endpoint path="/api/{version}/app/clinical/persons/actions/promote_to_user" method="POST" />

The API will require the `source_person_id` field and any fields the Vault requires to create a User as Body Parameters.
</ReleaseNote>

<ReleaseNote id="OOU0000000QP001" lr="26r1.3" app_family="regulatory" version="26r2">
### Submissions Archive Scalability Improvements

Veeva Submissions Archive has been updated for performance and reliability. As part of this feature, DAC security is unaffected, and the following have been enhanced:

*   Updated Export UI for single submissions
*   Multi-Submission Export from the *All Submissions* tab
*   Exports now separate submission files from static CSV manifests

<Aside>
In 26R3, Submissions Archive Binder substructures will be sunset. This means new imports into Submissions Archive and new submissions published-in-Vault using RIM Submissions Publishing will leverage a single Submissions Archive > Structure top-level Vault Binder component created in the Library. Therefore, customers must assess their integrations.
</Aside>

We have also introduced new API endpoints for Submissions Archive:

**Bulk Export Submissions**

Allows for the asynchronous export of multiple submissions across multiple applications in a single call.

<Endpoint path="/api/{version}/app/regulatory/submissions_archive/actions/bulk_export" method="POST" />

**Export Submission (Single)**

Initiates an asynchronous job for a single submission, replacing the legacy binder-based endpoint.

<Endpoint path="/api/{version}/app/regulatory/submissions_archive/{submission_record_id}/actions/export" method="POST" />

**Retrieve Submission Export Results**

Checks job status and retrieves the final output location on file staging.

<Endpoint path="/api/{version}/app/regulatory/submissions_archive/export_job/{job_id}" method="GET" />

**Retrieve Submission Import Results**

Retrieves *Informational*, *Warning* and *Data Entry* messages associated with a completed import job.

<Endpoint path="/api/{version}/app/regulatory/submissions_archive/{submission_record_id}/actions/import_results" method="GET" />
</ReleaseNote>

<ReleaseNote id="OOU0000000RR033" lr="26r1.3" app_family="clinical" version="26r2">
### Send to Sites API

This feature introduces an API endpoint that enables the distribution of *Safety Letters* to *Study Sites*. This functionality is already available in the UI, and now developers can perform this operation via Vault API. When leveraging the following endpoint, *Safety Letters* are sent to the provided sites bypassing the in-system filtering. Sending a request to this endpoint requires the *Safety Distribution* and the *Study Site ID*.

<Endpoint path="/api/{version}/app/clinical/safety_distributions/{id}/actions/send_to_select_sites" method="POST" />
</ReleaseNote>

<ReleaseNote id="OOU0000000RT044" lr="26r1.3" app_family="regulatory" version="26r2">
### Bulk Export Scalability Improvement

Veeva Submissions Archive exports are now more consistent. The single export dialog is updated, and users can now run bulk exports from the *Submissions* and *Applications* grid views. Export summary files are now `.csv` files, delivered in a separate compressed file. See the [Veeva Vault Help release notes](https://rn.veevavault.help/en/gr/whats-new-in-26r2/#OOU0000000RT044) for other considerations.

This is built on a new framework, enhancing performance and adding new API endpoints with greater flexibility.

**Bulk Export Submissions**

<Endpoint path="/api/{version}/app/regulatory/submissions_archive/actions/bulk_export" method="POST" />

**Export Submission (Single)**

<Endpoint path="/api/{version}/app/regulatory/submissions_archive/{submission_record_id}/actions/export" method="POST" />

**Retrieve Submission Export Results**

<Endpoint path="/api/{version}/app/regulatory/submissions_archive/export_job/{job_id}" method="GET" />
</ReleaseNote>

<ReleaseNote id="OOU0000000RS041" lr="26r1.3" app_family="qualityone" version="26r2">
### QualityOne Teams Migration API

Veeva QualityOne now supports creating QualityOne *Team* members for migration purposes. This endpoint requires the object record's external ID, the user name, and API name for the team role to be added.

<Endpoint path="/api/{version}/qualityone/qms/teams/vobjects/{object_name}/actions/migration" method="POST" />
</ReleaseNote>

## Direct Data API

<ReleaseNote id="OOU0000000QS044" lr="26r1.2" app_family="platform" version="26r2">
### Direct Data API: Additional Document Metadata in Workflow Extracts

This release, we are adding existing document and version VQL fields to the Workflow Item (`workflow_item__sys.csv`) and Workflow Task Item (`workflow_task_item__sys.csv`) extracts in Direct Data files.
</ReleaseNote>

## MDL

<ReleaseNote id="OOU0000000PI051" lr="26r1.2" app_family="platform" version="26r2">
### Control Binding for Object Fields

Object fields can now be configured so that they are bound to a control (UI elements built by Veeva). Fields with control bindings will display the control when added to a layout. In the past, Admins needed to configure controls directly on a page layout and sometimes swap it with a field.

A field with control binding will always be displayed using that control in the record detail view, record list view, and related object sections. This prevents the need to add the control to all layouts, making administration easier and less error prone.

To achieve this, we have added a new attribute, called `control_binding`, to the Object > Field and Objecttype > Typefield subcomponent's MDL.
</ReleaseNote>

<ReleaseNote id="OOU0000000RP002" lr="26r1.3" app_family="platform" version="26r2">
### Migration Package Validation Enhancements

Configuration migration package (VPK) validation improves the reliability of configuration deployments by enforcing SDK code compilation checks and detecting missing sub-component dependencies during the validation phase.

**SDK Code Validation**: Vault now performs a compilation of SDK source code included in a VPK during the validation step. If the code contains compilation errors, the validation process marks the specific code step with a *Blocked* status. This prevents the package from being deployed until the code issues are resolved.

**Enhanced Dependency Detection Validation**: Vault now checks for missing sub-components. Even if a parent component exists in the target Vault, the engine verifies that all referenced sub-components are also present. For example, if an object exists in the target Vault, the validation engine verifies that all fields are present.
</ReleaseNote>

<ReleaseNote id="OOU0000000QS048" lr="26r1.3" app_family="platform" version="26r2">
### Packages Support for Record Attachments & Attachment Fields

Vault configuration migration packages (VPKs) now support exporting and importing record attachments and attachment field files when exporting data.

After adding the Data Step (Dataset), you can edit the Dataset Item to enable *Include Object Record Attachments*, which will export record attachments. In the *Columns* sections of the Dataset Item, you can add attachment fields, which will also be included in the extract.

In the exported VPK, the attachments are stored in the step's folder structure:

*   Record attachments: `##### > content > row_# > recordattachments > file_name > v#`
*   Attachment fields: `##### > content > row_# > attachmentfields > field_name`

For each Data Step, an additional `DSET-#####-object_name-content.xml` is created in the step's folder, which details how the attachments need to be added to the records.

```xml
<contentmetadata>
 <component name="example_object__c" type="Object">
  <records>
   <record rowid="1">
    <recordattachments>
     <recordattachment name="export_1766945124021.csv">
      <version versionnumber="1">
      <source>components\00010\content\row_1\recordattachments\test.csv\v1\test.csv</source>
      </version>
     </recordattachment>
    </recordattachments>
    <attachmentfields>
     <attachmentfield name="attachment_field__c">
      <source>components\00010\content\row_1\attachmentfields\attachment_field__c\test.png</source>
     </attachmentfield>
    </attachmentfields>
   </record>
  </records>
 </component>
</contentmetadata>
```
</ReleaseNote>

<ReleaseNote id="OOU0000000QU032" lr="26r1.3" app_family="platform" version="26r2">
### Bitmask Field

This feature introduces a Bitmask field type for objects, enabling apps to securely filter records efficiently without performance degradations at high volumes.

Only Veeva can create Bitmask fields, and in MDL there is a new possible value `'Bitmask'` for the `type()` attribute of the `Object` > `Field` subcomponent.

In VQL, a new bitwise operator, `AND` (`&`), is added for Bitmask fields only.

The below example returns a list of master data that is unmasked according to user's permissions in the form of a bitmask value (40049) and the access group value (Bitmask field) stored on the record.

```sql
SELECT id, name__v, status__v 
FROM master_data__v 
WHERE access_group__v & 40049 > 0
```
</ReleaseNote>

<ReleaseNote id="OOU0000000RQ015" lr="26r1.3" app_family="platform" version="26r2">
### Layout Rules: Automatic Controlled Field Management

Layout rules now automatically add controlled fields when their controlling field is hidden, and controlling fields when their controlled field is displayed as required. Auto-added fields are locked with a tooltip naming the dependency, and existing layout rules stay in sync as field dependencies change.

This means the system will add additional fields to the `Layoutrules` component MDL when adding controlled or controlling fields.
</ReleaseNote>

<ReleaseNote id="OOU0000000QW046" lr="26r1.3" app_family="quality" version="26r2">
### Complaint Intake Follow-Up: Manual Processing

This feature adds support for managing manual *Complaint Intake Follow-Ups*. The feature will not be enabled until 26R3, but we have pre-loaded the components in Vaults. The components will not be visible to end users until the feature is turned on, but can show up on Vault Compare reports, and in the `Pagelayout` MDL.

`<vault:control reference="cifu_complaint_contacts_field_control__v" name="cifu_complaint_contacts_field_control__c" label="Complaint Contacts"/>`

`<vault:control reference="cifu_notification_template_field_control__v" name="cifu_notification_template_field_control__c" label="Email Template"/>`
</ReleaseNote>

<ReleaseNote id="OOU0000000RJ008" lr="26r1.3" app_family="quality" version="26r2">
### External Notifications: Alternate Communication Languages

This feature adds support for *Complaint Intake* and *Complaint* to send external emails in alternate languages using *Quality External Notifications*.

A new `configParameterValue` with name `extNotifUseCommunicationLanguage` is available in the `Objectlifecycleentryaction` for enabling this feature for the *Send a Notification* action on *Complaint Intake* and *Complaint* records:

```xml
<rule>
  <actions>
    <action type="Recordaction.com.veeva.vault.app.quality.qms.sendexternalnotification.action.SendExternalNotificationEntryAction">
      <configParameters>
        <configParameter valueType="Picklist" name="extNotifParam">
          <configParameterValue><![CDATA[complaint_intake_complaint_intake__c]]></configParameterValue>
        </configParameter>
        <configParameter valueType="Picklist" name="extNotifTemplateParam">
          <configParameterValue><![CDATA[ci_complaint_intake__c]]></configParameterValue>
        </configParameter>
        <configParameter valueType="Boolean" name="extNotifUseCommunicationLanguage">
          <configParameterValue><![CDATA[true]]></configParameterValue>
        </configParameter>
      </configParameters>
    </action>
  </actions>
</rule>
```
</ReleaseNote>

<ReleaseNote id="OOU0000000RQ003" lr="26r1.3" app_family="quality" version="26r2">
### External Notifications: Complaint Enhancements

Admins can now configure *External Notifications* for *Complaints* and *Quality Events* (*Complaint* and *Medtech Complaint* object types) to use the new *Complaint Contact* object to capture information about reporters and complainants.

This update introduces a new `recipient_option` attribute for the `Qualityexternalnotificationtemplate` MDL component, with the possible values `PERSON` or `COMPLAINT_CONTACT`.

If `COMPLAINT_CONTACT` is selected, the component will be expecting `Qualitynotificationcomplaintcontact` subcomponents, instead of completing the `recipients()` attribute.
</ReleaseNote>