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

# Developer Features in 24R1

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

## 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="24r1-record-triggers-return-correct-fields-for-new-object-type" app_family="platform" version="24r1" lr="24r1.0">### Record Triggers Return Correct Fields for New Object Type {#24r1-record-triggers-return-correct-fields-for-new-object-type}

When a record trigger executes due to an object type change, developers will now be able to get and set values on all object type fields that exist on the new object type.
Previously, developers could only set values for object type fields that exist in both the old and new object types.

With this change, `getNew()` will now return `null` values for fields that are not set for the new object type and return non-null values for fields that are set for the new object type.

</ReleaseNote>
<ReleaseNote id="24r1-external-url-reverse-ip-lookup-change" app_family="platform" version="24r1" lr="23r3.4">### External URL Reverse IP Lookup Change {#24r1-external-url-reverse-ip-lookup-change}

External URL jobs are now sent from an IP address associated with Veeva Vault. Organizations who are currently allowinglisting by domain must update their rules to support the `*.veevavault.com` domains.

</ReleaseNote>
<ReleaseNote id="24r1-non-consecutive-document-ids" app_family="platform" version="24r1" lr="23r3.2">### Non-consecutive Document IDs {#24r1-non-consecutive-document-ids}

When documents are created, Vault automatically assigns a document ID (note, this is different from Document Number). With v24.1, we are making changes to how Document IDs are generated to support future functionality. These changes will result in document IDs more frequently being non-sequential numbers.

There were already scenarios where Document IDs may not be sequential (i.e. due to document deletions), but these changes in v24.1 will result in Document IDs never being sequential.

Customers should assess any existing integrations if the Document ID is being used as a basis for document sequence. We do not recommend that the Document ID field be used as a means of identifying document creation order, but rather recommend the use of Document Number.

</ReleaseNote>
<ReleaseNote id="24r1-hvo-renamed-to-raw-with-new-one-billion-record-limit" app_family="platform" version="24r1" lr="23r3.2">### HVO Renamed to Raw with New One Billion Record Limit {#24r1-hvo-renamed-to-raw-with-new-one-billion-record-limit}

High volume objects are now called raw objects. As we look to increase the scalability of our standard objects, we will begin treating high volume objects more like regular database tables, used for storing raw data.
To make the purpose of these objects clearer, we are updating the terminology across our user and developer documentation and in the Vault UI and API, referring to this class of objects instead as raw objects.

There is now a limit of one billion records for raw objects. In addition, the `data_store` attribute for the `Object` MDL component now includes a value of `raw`. This change is backward compatible, and `high_volume` is still supported as an input value.

</ReleaseNote>

## Global Changes {#global-changes}

<ReleaseNote id="24r1-merge-records-api" app_family="platform" version="24r1" lr="23r3.4">### Merge Records API {#24r1-merge-records-api}

Duplicate records in Vault can happen due to migrations, integrations, or day-to-day activities. These duplicate records can be difficult to correct because of the many ways an object record can be referenced. For example, an object record may be referenced in both configuration and document and record relationships.

This feature allows developers with the *Application: Object: Merge Records* permission to merge two records using `main_record_id` and `duplicate_record_id` into a single record on Objects where the new setting, **Enable Merges**, is turned on. You can only turn on **Enable Merges** for custom objects.

During a record merge, Vault updates all inbound references from the *Duplicate* record to the *Main* record, including attachments. Field values on the *Main* record are not changed, and when the process is complete, the *Duplicate* record is deleted. SDK record triggers are not invoked during this process.

<Endpoint path="/api/{version}/vobjects/{object_name}/actions/merge" method="POST"></Endpoint>Developers can also use Vault Java SDK to invoke a merge records operation action using the `RecordMergeRequest` interface, and may also create **Record Merge Event Handlers** which can define custom logic for merging records. Only one event handler is allowed per object.
You can only initiate record merges through [Vault API](/vault-api/api-reference/24.1/vault-objects/merge-object-records) or the [Vault Java SDK](/vault-sdk/entry-points/record-merge/), and you can learn more about the Vault configuration required for merging records in [Vault Help](https://platform.veevavault.help/gr/659058).

</ReleaseNote>

## Vault API v24.1 {#vault-api-v241}

### Global Changes {#global-changes-1}

<ReleaseNote id="24r1-reference-id-for-vault-api" app_family="platform" version="24r1" lr="23r3.4">#### Reference ID for Vault API {#24r1-reference-id-for-vault-api}

`X-VaultAPI-ReferenceId` is a new API header that is defined by the client application calling Vault API. When using API v24.1+, and the API request includes a value for this header, Vault API will return the value in the API response and include it in the API usage logs when downloaded using Vault API v24.1+ or from the Vault Admin UI.

</ReleaseNote>
<ReleaseNote id="24r1-vault-api-read-and-delete-annotations" app_family="platform" version="24r1" lr="23r3.4">#### Vault API: Read and Delete Annotations {#24r1-vault-api-read-and-delete-annotations}

In API v24.1+, we have deprecated the following endpoints and replaced them with new endpoints. The new endpoints are identical, with the exception that they now end with the `/file` resource:

* [Export Document Annotations to PDF](/vault-api/api-reference/24.1/documents/document-annotations/export-document-annotations-to-pdf)

* [Export Document Version Annotations to PDF](/vault-api/api-reference/24.1/documents/document-annotations/export-document-version-annotations-to-pdf)

* [Import Document Annotations from PDF](/vault-api/api-reference/24.1/documents/document-annotations/import-document-annotations-from-pdf)

* [Import Document Version Annotations from PDF](/vault-api/api-reference/24.1/documents/document-annotations/import-document-version-annotations-from-pdf)

Previous API versions will continue to support the deprecated endpoints without `/file`. If you are upgrading an existing integration to API v24.1+, you must use the new endpoints which end in `/file`.

In addition, this feature introduces the new [Read Annotations by Document Version and Type](/vault-api/api-reference/24.1/documents/document-annotations/read-annotations-by-document-version-and-type) API endpoint that will return annotations as JSON, and allow users to paginate results and filter annotations by type using optional query parameters, such as `annotation_types`, `limit`, `offset`, and `pagination_id`:

<Endpoint path="/api/{version}/objects/documents/{doc_id}/versions/{major_version}/{minor_version}/annotations" method="GET"></Endpoint>The above API also returns the Annotation ID `id__sys`, which can be directly called using the new [Read Annotations by ID](/vault-api/api-reference/24.1/documents/document-annotations/read-annotations-by-id) API endpoint:

<Endpoint path="/api/{version}/objects/documents/{doc_id}/versions/{major_version}/{minor_version}/annotations/{annotation_id}" method="GET"></Endpoint>Developers may also get replies to a specific Annotation ID using the [Read Replies by Parent ID](/vault-api/api-reference/24.1/documents/document-annotations/read-replies-of-parent-annotation) endpoint, and use optional parameters `limit`, `offset`, and `pagination_id`:

<Endpoint path="/api/{version}/objects/documents/{doc_id}/versions/{major_version}/{minor_version}/annotations/{annotation_id}/replies" method="GET"></Endpoint>The last update of this feature is the [Delete Annotations](/vault-api/api-reference/24.1/documents/document-annotations/delete-annotations) endpoint, which can be used to delete annotations in a batch by providing `document_id__v`, `major_version__v`, `major_version__v`, and `annotation_id__v` as nodes in a JSON payload:

<Endpoint path="/api/{version}/objects/documents/annotations/batch" method="DELETE"></Endpoint></ReleaseNote>
<ReleaseNote id="24r1-direct-data-api" app_family="platform" version="24r1" lr="23r3.4">#### Action Layouts: Summary Fields {#action-layouts-summary-fields}

The 23R3.4 extension of the Action Layouts feature will introduce *Summary Fields* which will be accessible for  `Object` and `Objecttype` components via MDL using the `summary_fields` attribute. Learn more about [Object](/mdl/component-reference/component-types/object) and [Objecttype](/mdl/component-reference/component-types/objecttype) components.

For SDK, the `summary_fields` attribute can be obtained using the `getSummaryFields()` method for both the `ObjectMetadata` and `ObjectTypeMetadata` interfaces.

Learn more in the [javadocs](https://repo.veevavault.com/javadoc/vault-sdk-api/25.3.2/docs/api/index.html).

</ReleaseNote>

### New Endpoints {#new-endpoints}

<ReleaseNote id="24r1-direct-data-api" app_family="platform" version="24r1" lr="23r3.5">#### Direct Data API {#24r1-direct-data-api}

The Direct Data API is a new class of API that provides high-speed read-only data access for Vault applications. Direct Data is a reliable, easy-to-use, timely, and consistent API for extracting Vault data. Using the API, customers can easily replicate Vault data in external data warehouses and data lakes.

<s>The Direct Data API is an add-on license available for any Vault.</s> When enabled, it will generate .gzip files containing several extracts. Extract CSVs include object records, document version metadata (excluding annotation count fields) picklists, and audit data.

There are three types of Direct Data files:

* **Full**: contains a complete set of data starting from the time the Vault was created to the current date published once a day.

* **Incremental**: contains an incremental set of data published for each 15-minute interval.

* **Log**: contains the Login, System, Object, and Document audit trails for a single day.

Learn more about the [Direct Data API](/direct-data-api/).

</ReleaseNote>
<ReleaseNote id="24r1-bulk-rendition-operations" app_family="platform" version="24r1" lr="23r3.4">#### Bulk Rendition Operations {#24r1-bulk-rendition-operations}

As a result of a configuration change or migration project, there may be a need to re-render a substantial amount of documents. This new endpoint accepts a CSV file with document IDs to initiate a bulk re-render operation.

<Endpoint path="/api/{version}/objects/documents/batch/actions/rerender" method="POST"></Endpoint>View this endpoint in the [v24.1 Vault API Reference](/vault-api/api-reference/24.1/documents/document-renditions/update-multiple-document-renditions).

</ReleaseNote>
<ReleaseNote id="24r1-end-session-endpoint" app_family="platform" version="24r1" lr="23r3.4">#### End Session Endpoint {#24r1-end-session-endpoint}

This new Vault API endpoint ends a Vault session. This allows integrations to end the Vault session instead of letting the session expire. If a user has more than one active session, ending one session does not affect the user's other sessions. For example, ending a user’s API session will not affect their active UI sessions.

<Endpoint path="/api/{version}/session" method="DELETE"></Endpoint>View this endpoint in the [v24.1 Vault API Reference](/vault-api/api-reference/24.1/authentication/end-session).

</ReleaseNote>

### Existing Endpoints {#existing-endpoints}

<ReleaseNote id="24r1-warnings-and-error-messages-in-api-usage-logs" app_family="platform" version="24r1" lr="23r3.4">#### Warnings and Error Messages in API Usage Logs {#24r1-warnings-and-error-messages-in-api-usage-logs}

API Usage Logs will now include error and warning messages that appear in the CSV file output. New columns will include `api_response_warning_message` and `api_response_error_message`.

Additionally, the `X-VaultAPI-ReferenceId` header will be included in the API Usage Logs with column `reference_id`.

These columns are included when downloaded using the Vault UI or API v24.1+.

</ReleaseNote>
<ReleaseNote id="24r1-new-object-audit-fields-in-csv-exports-and-api" app_family="platform" version="24r1" lr="23r3.2">#### New Object Audit Fields in CSV Exports and API {#24r1-new-object-audit-fields-in-csv-exports-and-api}

The object audit API (CSV and JSON) and data exports from the Vault UI (CSV) now include new fields that display the API names for fields, objects, new values, and old values. The affected endpoints are:

<Endpoint path="/api/{version}/vobjects/{object_name}/{object_record_id}/audittrail" method="GET"></Endpoint><Endpoint path="/api/{version}/audittrail/object_audit_trail" method="GET"></Endpoint>These new fields make it easier to join audit data with other Vault data and to perform additional analysis of audit data in external systems. This feature is automatically part of API v24.1.

</ReleaseNote>
<ReleaseNote id="24r1-workflow-initiators-select-task-assignment-type" app_family="platform" version="24r1" lr="23r3.4">#### Workflow Initiators Select Task Assignment Type {#24r1-workflow-initiators-select-task-assignment-type}

Vault now allows workflow initiators to select whether a task is assigned to *Any* or *Every* participant in a participant control of a workflow start step. This choice is enabled when configuring a workflow task and is stored in the MDL of the workflow component as the following XML tag `<vwf:assignmentType type="runtimeChoice" />`.

When using Vault API to start a workflow where workflow initiators can select the assignment type, the system will expect a value of `assigned` (assigned to all users) or `available` (available to any user) for the `{participant_group}.assignment_type__c` body parameter.

Learn more about [starting a workflow with Vault API](/vault-api/api-reference/24.1/object-lifecycle-workflows/object-record-user-actions/initiate-object-action-on-a-single-record).

</ReleaseNote>
<ReleaseNote id="24r1-workflow-api-error-type-updates-for-adding-participants" app_family="platform" version="24r1" lr="23r3.2">#### Workflow API Error Type Updates for Adding Participants {#24r1-workflow-api-error-type-updates-for-adding-participants}

When using the Initiate Workflow Action endpoint to add participants or reassign tasks, if the workflow is configured to use either the *Use Role as Participants* or *Use Custom Action to Define Participants* option on participant controls, the API now returns an `INVALID_DATA` error type if the attempted action is not consistent with the participant control settings.

</ReleaseNote>
<ReleaseNote id="24r1-binder-limits" app_family="platform" version="24r1" lr="23r3.2">#### Binder Limits {#24r1-binder-limits}

Vault now has clearly documented and enforced limits for Vault Binders to ensure good binder performance. Developers will be able to use binders in a predictable and easy to understand way. For all API versions, the following limits now apply to binders:

* Binders cannot exceed 50,000 nodes, including component binders. If a binder has reached its limit, binder nodes cannot be added to the binder or any of its component binders, even if the component binders have not reached the 50,000 node limit.

* Binders cannot be versioned via *Create Draft* or copied if it exceeds 10,000 nodes, including the nodes within component binders. Vault will still execute the *Set New Major Version* entry action on binders which exceed 10,000 nodes.

These limits will apply to the following endpoints for all API versions:

<Endpoint path="/api/{version}/objects/binders/templates/{template_name}/bindernodes" method="POST"></Endpoint><Endpoint path="/api/{version}/objects/binders/{binder_id}/documents" method="POST"></Endpoint><Endpoint path="/api/{version}/objects/binders/{binder_id}/sections" method="POST"></Endpoint><Endpoint path="/api/{version}/objects/binders/templates" method="PUT"></Endpoint>If your organization has binders that are currently over any of these limits, the Veeva Account Team will be reaching out directly.

</ReleaseNote>
<ReleaseNote id="24r1-document-templates-limit" app_family="platform" version="24r1" lr="23r3.2">#### Document Templates Limit {#24r1-document-templates-limit}

Vault now has clearly documented and enforced limits for Basic and Controlled Document Templates to ensure reliable document template performance.

* Each Vault now has a limit of:

* 50 document templates at the Base Document type

* 500 document templates per document hierarchy

* 5,000 document templates per Vault

These limits will apply to the following endpoints for all API versions:

<Endpoint path="/api/{version}/objects/documents/templates" method="POST"></Endpoint><Endpoint path="/api/{version}/objects/{documents_or_binders}/{id}/versions/{major_version}/{minor_version}/lifecycle_actions/{name__v}" method="PUT"></Endpoint>If your organization has document templates that are currently over any of these limits, the Veeva Account Team will be reaching out directly.

</ReleaseNote>
<ReleaseNote id="24r1-action-layouts-layout-profiles" app_family="platform" version="24r1" lr="23r3.2">#### Action Layouts: Layout Profiles {#24r1-action-layouts-layout-profiles}

Admins can now configure Layout Profiles that can define what Layouts are available to users on object records. With this enhancement, as new Layouts are configured on objects, customers can also assign what each user should see by default and what additional layouts should be available to them to switch between.

In API v24.1, when using the [Create Object Records](/vault-api/api-reference/24.1/vault-objects/create-object-records) or [Update Object Records](/vault-api/api-reference/24.1/vault-objects/update-object-records) endpoints to create or update Users, a new standard field called `layout_profile__sys` will be available.

<Endpoint path="/api/{version}/vobjects/{object_name}" method="POST"></Endpoint>
<Endpoint path="/api/{version}/vobjects/{object_name}" method="PUT"></Endpoint>
This feature adds the new [`Layoutprofile` component](/mdl/component-reference/component-types/layoutprofile) type to all Vaults.

</ReleaseNote>
<ReleaseNote id="24r1-action-layouts-layout-pages" app_family="platform" version="24r1" lr="23r3.2">#### Action Layouts: Layout Pages {#24r1-action-layouts-layout-pages}

Admins can now optionally configure up to 10 separate Pages in a Layout. Pages contain sections to  allow for grouping them into more focused displays so that users can navigate between each Page based on the context and work to be done. By default, all existing layouts will remain unchanged, but the user interface for the left-hand navigation will appear slightly cleaner, and users will have the option to minimize the menu, allowing for a full-screen view.

In API v24.1, the Retrieve Page Layout Metadata endpoint will now include information (Label, Name, and Section) on any configured Pages, if more than one exists in a given layout. In addition, the [Retrieve Page Layouts](/vault-api/api-reference/24.1/vault-objects/object-page-layouts/retrieve-page-layouts) and [Retrieve Page Layout](/vault-api/api-reference/24.1/vault-objects/object-page-layouts/retrieve-page-layout-metadata) Metadata endpoints will include additional information (such as Description, Status, Default, and Display Lifecycle Stages).

<Endpoint path="/api/{version}/metadata/vobjects/{object_name}/page_layouts" method="GET"></Endpoint><Endpoint path="/api/{version}/metadata/vobjects/{object_name}/page_layouts/{layout_name}" method="GET"></Endpoint>This feature adds the following attributes to the [`Pagelayout` component](/mdl/component-reference/component-types/pagelayout) type:

* `default_layout`

* `active`

* `description`

* `display_lifecycle_stages`

</ReleaseNote>
<ReleaseNote id="24r1-action-layouts-layout-rules-enhancement" app_family="platform" version="24r1" lr="23r3.2">#### Action Layouts: Layout Rules Enhancement {#24r1-action-layouts-layout-rules-enhancement}

To further enable the flexibility in these Layout changes, we have also enhanced Layout Rules.

Layout Rules are applied to each Layout and any Layout Pages within, but with the introduction of Layout Pages, rules can now be defined to hide or show Views and Pages within Layouts. Additionally, a new Layout Selection Rule is available called Focus On, which allows Admins to define criteria for overriding a default Layout.

There is also a new *Display as Required* option, which allows fields to be displayed as required fields based on the Layout Rule Expression - this can reduce the potential for users to encounter Entry Criteria errors by ensuring that fields display as required in the right circumstances.

In API v24.1, the [Retrieve Page Layout Metadata](/vault-api/api-reference/24.1/vault-objects/object-page-layouts/retrieve-page-layout-metadata) endpoint will now include additional layout rule information, such as hiding view and pages, requiring field input and displaying view as selected.

<Endpoint path="/api/{version}/metadata/vobjects/{object_name}/page_layouts/{layout_name}" method="GET"></Endpoint>This feature adds the following attributes to the [`Layoutrule` component](/mdl/component-reference/component-types/layoutrule) type:

* `hide_layout`

* `focus_on_layout`

* `hidden_pages`

* `displayed_as_required_fields`

</ReleaseNote>
<ReleaseNote id="24r1-action-layouts-additional-improvements" app_family="platform" version="24r1" lr="23r3.4">#### Action Layouts: Additional Improvements {#24r1-action-layouts-additional-improvements}

Users can now create up to 50 custom layouts per *Object - Object Type Pair*, regardless of how many system or standard layouts there are. The previous limit was 20 custom layouts.

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

</ReleaseNote>
<ReleaseNote id="24r1-clinical-edl-override-automation-template-hierarchy-and-usability-enhancements" app_family="clinical" version="24r1" lr="23r3.4">#### Clinical: EDL Override: Automation, Template Hierarchy, and Usability Enhancements {#24r1-clinical-edl-override-automation-template-hierarchy-and-usability-enhancements}

A new Vault API endpoint will be made available to generate Milestone Documents in bulk. The endpoint will accept a CSV file of up to 500 records.

<Endpoint path="/api/{version}/app/clinical/milestone/actions/generatemilestonedocuments" method="POST"></Endpoint></ReleaseNote>

## VQL {#vql}

<ReleaseNote id="24r1-tolabel" app_family="platform" version="24r1" lr="23r3.4">### TOLABEL {#24r1-tolabel}

In VQL, the `TOLABEL()` function will return the localized label of referenced components for the lifecycle states and picklist values of standard volume objects. Raw objects (formerly high volume objects) are not currently supported.

With this function, developers no longer need to convert and match name values to labels with a separate API call or hard-coded dictionary. This allows the API call to retrieve user-facing values in a single step.

Learn more about [the `TOLABEL()` function](/vql/functions-options/tolabel).

</ReleaseNote>
<ReleaseNote id="24r1-document-attachments" app_family="platform" version="24r1" lr="23r3.4">#### Document Attachments {#24r1-document-attachments}

VQL queries can now access document attachment metadata via the `attachments__sysr` relationship. Developers must query attachments as subqueries in the `SELECT` or `WHERE` clauses. Document attachment subqueries support the `ALLVERSIONS` option.

Learn more about [querying document attachments](/vql/query-targets/attachments#Document_Attachments).

</ReleaseNote>
<ReleaseNote id="24r1-sdk-job-enhancements-vql-for-sdk-jobs" app_family="platform" version="24r1" lr="23r3.4">#### SDK Job Enhancements: VQL for SDK Jobs {#24r1-sdk-job-enhancements-vql-for-sdk-jobs}

To allow better control over SDK jobs, developers can now use the `job_instance__sys` VQL query target to find a running job and retrieve the job status and other job metadata.

Learn more about [querying job instances](/vql/query-targets/jobs#Job_Instances).

</ReleaseNote>

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

### Global Changes {#global-changes-2}

<ReleaseNote id="24r1-user-object-trigger-support" app_family="platform" version="24r1" lr="23r3.4">#### User Object: Trigger Support {#24r1-user-object-trigger-support}

Vault now supports SDK record triggers on the `user__sys` object. Record triggers are only invoked when changes are made directly to the `user__sys` object on the Vault. Triggers on the `user__sys` object are not invoked for domain attribute updates (such as first name or last name) originating from other Vaults.

Learn more about [user triggers](/vault-sdk/entry-points/triggers/record-triggers/anatomy-record-triggers/#User_Triggers).

</ReleaseNote>

### New Interfaces & Methods {#new-interfaces--methods}

<ReleaseNote id="24r1-retrieve-vault-domain-name" app_family="platform" version="24r1" lr="23r3.2">#### Retrieve Vault Domain Name {#24r1-retrieve-vault-domain-name}

A new method, `getDomain()`, is now available in the `VaultInformation` interface that can be used to retrieve the domain name for a given Vault.

</ReleaseNote>
<ReleaseNote id="24r1-document-lifecycle-services-sdk" app_family="platform" version="24r1" lr="23r3.4">#### Document Lifecycle Services SDK {#24r1-document-lifecycle-services-sdk}

This feature introduces Document Lifecycle Services to the Vault Java SDK to
retrieve configuration metadata about document lifecycles and lifecycle user actions. It also provides methods to execute user actions and state changes on documents.

Learn more about [Document Lifecycle Services](/vault-sdk/services/lifecycle-services/#Document_Lifecycle_Services).

</ReleaseNote>
<ReleaseNote id="24r1-new-capabilities-for-annotations" app_family="platform" version="24r1" lr="23r3.4">#### New capabilities for Annotations {#24r1-new-capabilities-for-annotations}

Vault Java SDK will now support creating and editing text annotations using coordinates.

When retrieving annotations via SDK, it will also include **Modified by User** (`modified_by_user_sys`) and Modified Date Time (`modified_date_time_sys`) fields. The values of fields will default to **Created By** and **Created Date** information when the last modified information does not exist for an annotation.

Learn more about [Annotation Services](/vault-sdk/services/annotation-services).

</ReleaseNote>
<ReleaseNote id="24r1-sdk-job-enhancements-cancel-sdk-jobs" app_family="platform" version="24r1" lr="23r3.4">#### SDK Job Enhancements: Cancel SDK Jobs {#24r1-sdk-job-enhancements-cancel-sdk-jobs}

Developers can now cancel an SDK job using the `cancelJob()` method in the Vault Java SDK. Custom SDK code can only cancel custom SDK jobs. This can be used to avoid multiple async jobs running at the same time, which could lead to inaccurate results.

</ReleaseNote>
<ReleaseNote id="24r1-sdk-job-enhancements-job-task-retry" app_family="platform" version="24r1" lr="23r3.4">#### SDK Job Enhancements: Job Task Retry {#24r1-sdk-job-enhancements-job-task-retry}

Developers can now retry a `JobTask` during SDK job execution using the `setRetry(Boolean retry)` method. Tasks can only be retried up to five (5) times, and the SDK must be annotated as `idempotent=true`. This feature can be used to increase the resilience of code in case of temporary errors, such as thread lock conflict or unavailable system resources.

</ReleaseNote>
<ReleaseNote id="24r1-sdk-job-enhancements-retrieve-job-owner" app_family="platform" version="24r1" lr="23r3.4">#### SDK Job Enhancements: Retrieve Job Owner {#24r1-sdk-job-enhancements-retrieve-job-owner}

Developers can now get the owner(s) of a job or the initiating user of a one-time job using the `getJobOwner()` method. This function can be used to alert the job owner about the status of the job.

The returned JobOwner provides two methods:

* `getId()` to retrieve the user or group ID

* `getType()` to determine whether the owner is a user or a group

</ReleaseNote>
<ReleaseNote id="24r1-edl-sdk-manual-matching-of-documents" app_family="platform" version="24r1" lr="23r3.2">#### EDL SDK: Manual Matching of Documents {#24r1-edl-sdk-manual-matching-of-documents}

To support customers who use EDL manual matching, we are introducing an SDK interface to enable the manual matching and unmatching of documents to EDL Items. In comparison, the API can be used to manually add, remove, lock, and unlock documents from EDL Items, but it does not support excluding and including automatically matched documents.

The EDL service provides methods to perform the following actions for manual matching:

* Add and remove a document

* Lock and unlock a document

* Exclude and include an automatically matched document

</ReleaseNote>

### Existing Interfaces & Methods {#existing-interfaces--methods}

<ReleaseNote id="24r1-record-service-enhancements" app_family="platform" version="24r1" lr="23r3.4">#### Record Service Enhancements {#24r1-record-service-enhancements}

This feature enables developers to change the object type of a record as well as to save a record in migration mode via the Java SDK Record Service.

Two optional methods are added to `RecordBatchSaveRequest.Builder`:

* `Builder withAllowObjectTypeChange(boolean allowObjectTypeChange)`

* `Builder withMigrationMode(boolean migrationMode)`

If `migrationMode` is set to `true`, the system will allow the creation or update of object records in any lifecycle state or state type. Additionally, Vault bypasses entry criteria, entry actions, validation rules, event actions, and reference constraints when creating or updating records in migration mode.

</ReleaseNote>
<ReleaseNote id="24r1-object-metadata-service-enhancements" app_family="platform" version="24r1" lr="23r3.2">#### Object Metadata Service Enhancements {#24r1-object-metadata-service-enhancements}

This feature enhances the SDK Object Metadata Service in the following ways:

* Developers now have the ability to retrieve the join type on an object. The join type can be Simple, Complex, or Undefined (for any objects that are not used as a join object). A potential use case for this feature is writing VQL queries based on the join type of an object.

* Developers now have the ability to retrieve picklist field dependencies on any object picklist fields.  A potential use case for this feature is setting picklist field values according to the picklist field dependencies, ensuring the same data integrity that would be enforced for users.

</ReleaseNote>
<ReleaseNote id="24r1-enhancements-to-query-field-type" app_family="platform" version="24r1" lr="23r3.2">#### Enhancements to Query Field Type {#24r1-enhancements-to-query-field-type}

Field rules now allow using a different `SELECT` field than the Query field in the field rule. This will be used by app developers/customers to get required field value without overloading the Query Field.

To achieve this, we’re introducing a new **Query Field Select** attribute (`query_field_select`).

The attribute will be recommended on Field Rules used in Vault to Vault Connections, but will not be required for field rules on local or external connections.

</ReleaseNote>

## MDL {#mdl}

### Platform MDL {#platform-mdl}

<ReleaseNote id="24r1-enhanced-dashboards-tab" app_family="platform" version="24r1" lr="23r3.4">#### Enhanced Dashboards Tab {#24r1-enhanced-dashboards-tab}

The `Dashboard` component type now includes the `tags` attribute, which returns a list of tags associated with the Dashboard.

Learn more about [Dashboard components](/mdl/component-reference/component-types/dashboard).

</ReleaseNote>
<ReleaseNote id="24r1-reusable-labels-for-document-field-layouts" app_family="platform" version="24r1" lr="23r3.4">#### Reusable Labels for Document Field Layouts {#24r1-reusable-labels-for-document-field-layouts}

Vault will no longer enforce the uniqueness of the `label` attribute of `Docfieldlayout` components. Uniqueness will still be enforced on the name.

Learn more about [Docfieldlayout components](/mdl/component-reference/component-types/docfieldlayout).

</ReleaseNote>
<ReleaseNote id="24r1-layout-rule-display-as-read-only-effect" app_family="platform" version="24r1" lr="23r3.4">#### Layout Rule: Display As Read-Only Effect {#24r1-layout-rule-display-as-read-only-effect}

Admins can now configure Layout Rules to display fields as read-only. This feature adds a new `displayed_as_readonly_fields` attribute, which accepts a comma-separated list of field names, to the `Layoutrule` component.

Learn more about [Layoutrule components](/mdl/component-reference/component-types/layoutrule).

</ReleaseNote>
<ReleaseNote id="24r1-notification-categories-email-preferences" app_family="platform" version="24r1" lr="23r3.2">#### Notification Categories & Email Preferences {#24r1-notification-categories-email-preferences}

Admins can now specify a notification category for each notification template. Admins can also now define the frequency of notifications Vault sends by email. A frequency of **Never** treats the notification like an in-app notification only.
The `Notificationtemplate` component has two new attributes to support this: `notification_category` and `email_preferences`.

Learn more about [Notificationtemplate compnents](/mdl/component-reference/component-types/notificationtemplate).

</ReleaseNote>

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

<ReleaseNote id="24r1-qms-quality-teams-related-object-security" app_family="quality" version="24r1" lr="23r3.4">#### QMS: Quality Teams Related Object Security {#24r1-qms-quality-teams-related-object-security}

Quality Team Related Object Security dynamically adds a user to a specific role on a related object if that related object is an identified object associated with a Quality Team-enabled object. This feature allows Quality Team members to dynamically edit or delete records associated with a Quality Team-enabled process in a secure and scalable way and restricts modification of the records if they are not part of the parent Quality Team.

This feature uses the `Qualityteam` component type's new subcomponent, `Qualityteamrelatedobjectsecurity`, together with the new `Appsecurityrule` component type. These can be used to configure Related Object Security via the MDL API and to transfer the configuration using Vault Deployment Packages (VPK).

Learn more about [Qualityteam components](/mdl/component-reference/component-types/qualityteam).

</ReleaseNote>
<ReleaseNote id="24r1-qms-external-notifications-enhancements-multiple-recipients-and-add-document-from-library" app_family="quality" version="24r1" lr="23r3.4">#### QMS: External Notifications Enhancements: Multiple Recipients and Add Document from Library {#24r1-qms-external-notifications-enhancements-multiple-recipients-and-add-document-from-library}

Organizations often use *External Notifications* to correspond with stakeholders outside their companies about product complaints through email. This correspondence often involves multiple people identified on a *Complaint* record, like the initial reporter, the complainant, and healthcare providers.

Prior to this release, users were required to initiate one *External Notification* for each *Person* identified on a record. With the 24R1 release, Admins can configure an *External Notification* that allows users to send one email to multiple *Persons* on a record.

To support this functionality, this feature adds a new `Qualityexternalnotificationtemplate` Component Type to all Quality Vaults with QMS enabled.

Learn more about [Qualityexternalnotificationtemplate components](/mdl/component-reference/component-types/qualityexternalnotificationtemplate).

</ReleaseNote>
<ReleaseNote id="24r1-quality-incidents-create-a-quality-incident-from-a-qr-code-qms" app_family="quality" version="24r1" lr="23r3.4">#### Quality Incidents: Create a Quality Incident from a QR Code (QMS) {#24r1-quality-incidents-create-a-quality-incident-from-a-qr-code-qms}

Veeva QMS enables users to create *Quality Incident* records that capture information known at the time the incident is encountered, and includes a lightweight process that allows the appropriate individuals to triage the incident and determine if a full-fledged quality event process is necessary. System administrators can now configure QR codes to be printed and placed anywhere employees or contractors work. Veeva QMS users can scan QR codes with their mobile device’s camera to fill out a streamlined page that collects required information about the incident they encountered.

This new feature introduces a new `Qualityincidentintakelayout` Component Type for MDL.

</ReleaseNote>
<ReleaseNote id="24r1-qms-duplicate-check-check-lifecycle-state-processing-enhancement" app_family="quality" version="24r1" lr="23r3.2">#### QMS: Duplicate Check: Check Lifecycle State Processing Enhancement {#24r1-qms-duplicate-check-check-lifecycle-state-processing-enhancement}

In support of new changes to the Record Check: Duplicate Checks feature set, the `Qualityrecordcheck` component has a new attribute, `lifecycle_states_to_not_transition`. This optional attribute is only applicable to Duplicate Check types of Record Checks. Setting this attribute to a list of one or more lifecycle states shall prevent instances of the `Qualityrecordcheck` from performing lifecycle state transitions on matched records in one of those states.

</ReleaseNote>
<ReleaseNote id="24r1-validation-management-printable-view-for-test-scripts" app_family="platform" version="24r1" lr="23r3.4">#### Validation Management: Printable View for Test Scripts {#24r1-validation-management-printable-view-for-test-scripts}

With 24R1, Veeva Validation Management will provide a way to generate a printable view of a test script that will include related object records and evidence collected from executors, such as screenshots, that are stored as test step file attachments. With the introduction of printable views, a new `Printableviewtestscript` component type will be available via MDL. The component references two files as attributes: `template` (XML) and `header_logo` (*.png, *.jpg, *.jpeg, *.bmp, *.gif, *.svg, *.tif, *.tiff).

</ReleaseNote>