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

# Vault Developer Release Notes

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

## Developer Features in 23R2 {#developer-features-in-23r2}

We are pleased to bring you the following additions and enhancements to Developer Portal features in 23R2. REST API features added in 23R2 only affect API v23.2, unless otherwise noted.

## Service Announcements {#service-announcements}

<ReleaseNote id="23r2-http2" label="23R2" app_family="platform" version="23r2">### HTTP/2 {#23r2-http2}

In 23R2, Vault will enable support for the HTTP/2 protocol. Developers can choose to use HTTP/2, but upgrading is not required.

Before Vault begins supporting HTTP/2, developers should evaluate existing integrations that might be designed to auto-upgrade their HTTP protocol for compatibility with HTTP/2. For example, HTTP/2 returns all API headers as lowercase, which may be an issue if an existing integration is expecting case-sensitive header values.

</ReleaseNote>

## REST API v23.2 {#rest-api-v232}

### Global Changes {#23r2-global-changes}

<ReleaseNote id="23r2-intelligent-record-update" lr="23r1.2" app_family="platform" version="23r2">### Intelligent Record Update {#23r2-intelligent-record-update}

Vault will now only update object records if any changes have been made. Prior to this release, if a record was saved without any changes being made, it would count as an update. As a result, all record update related transactions would occur, such as updating the *Last Modified Date*, creating an audit trail entry, and firing SDK record triggers. In 23R1.2, these transactions will no longer occur for no-change saves.

With API v23.2 or later, if an API call to [upsert](/vault-api/api-reference/23.2/vault-objects/update-object-records) or [update](/vault-api/api-reference/23.2/vault-objects/update-object-records) records results in no changes, the API response will include a warning of either `No changes in values - record not updated` (for single records) or `No changes in values - one or more records not updated` (for multiple records). In this case, the record’s *Last Modified Date* is not changed (v23.2 or later), SDK record triggers do not execute (all versions), and Vault does not create an event in the Object Record Audit History (all versions).

If an SDK code to update records results in no changes, the SDK Runtime Log will include a warning of `No changes in values - one or more records not updated`. The record’s *Last Modified Date* is not changed, SDK record triggers do not execute, and Vault does not create an event in the Object Record Audit History.

</ReleaseNote>
<ReleaseNote id="23r2-api-response-status-insights" lr="23r1.3" app_family="platform" version="23r2">### API Response Status Insights {#23r2-api-response-status-insights}

Vault Admins can now see whether daily API Usage Logs contain Success, Failures, and Warnings. This allows Vault Admins to quickly inspect their Vault API usage and know if they need to download the log for further investigation.

Insights are only available for API calls made after the release of 23R2.

</ReleaseNote>
<ReleaseNote id="23r2-xvaultapistatus" lr="23r1.3" app_family="platform" version="23r2">### X-VaultAPI-Status {#23r2-xvaultapistatus}

A new response header, X-VaultAPI-Status, reflects the value of responseStatus in the JSON/XML response returned by Vault API and is intended for external reporting use cases. This new header is returned only in API v23.2+.

</ReleaseNote>

### New Endpoints {#23r2-new-endpoints}

<ReleaseNote id="23r2-bulk-reclassify-through-api" lr="23r1.3" app_family="platform" version="23r2">### Bulk Reclassify through API {#23r2-bulk-reclassify-through-api}

Customers often need to bulk reclassify due to large scale changes to document types. Developers now have the ability to bulk reclassify the latest version of documents using the new Reclassify Multiple Documents endpoint. This will also support future reference model changes for Veeva eTMF customers, who might require the reclassification of existing documents.

<Endpoint path="/api/{version}/objects/documents/batch/actions/reclassify" method="PUT"></Endpoint>With this change, the new endpoint and the existing [Reclassify Document](/vault-api/api-reference/23.2/documents/update-documents/reclassify-single-document) endpoint will also support migration mode. Migration mode allows users to set the document status and document number while reclassifying. The maximum batch size for bulk reclassification is 500 documents.

</ReleaseNote>

### Existing Endpoints {#23r2-existing-endpoints}

<ReleaseNote id="23r2-api-audit-trail-filtering-by-events" lr="23r1.2" app_family="platform" version="23r2">### API Audit Trail Filtering by Events {#23r2-api-audit-trail-filtering-by-events}

This feature allows API users to filter individual object record and document audit trails by specific events. To filter by event, add the new `events` query parameter to the existing [Audit History](/vault-api/api-reference/23.2/logs/audit-history) endpoints.

</ReleaseNote>
<ReleaseNote id="23r2-faster-performance-for-rendition-creation-with-single-document-create-api" lr="23r1.2" app_family="platform" version="23r2">### Faster Performance for Rendition Creation with Single Document Create API {#23r2-faster-performance-for-rendition-creation-with-single-document-create-api}

In this release, we’ve improved rendition generation performance when calling the [Create Single Document](/vault-api/api-reference/23.2/documents/create-documents/create-single-document) endpoint many times in a row. For the best performance, it is good practice to use the [Create Multiple Documents](/vault-api/api-reference/23.2/documents/create-documents/create-multiple-documents) endpoint if you need to create more than 100 documents at once.

Starting with v23.2, the Create Single Document endpoint will return `WARNING` instead of `SUCCESS` if it is used to create more than 100 documents at once.

</ReleaseNote>
<ReleaseNote id="23r2-limits-on-create-edit-annotations" lr="23r1.2" app_family="platform" version="23r2">### Limits on Create & Edit Annotations {#23r2-limits-on-create-edit-annotations}

Admins using the [Upload Document Annotations](/vault-api/api-reference/23.2/documents/document-annotations/upload-document-annotations) and [Upload Document Version Annotations](/vault-api/api-reference/23.2/documents/document-annotations/upload-document-version-annotations) endpoints will now see character limits enforced by Vault.

<Endpoint path="/api/{version}/objects/documents/{doc_id}/annotations" method="POST"></Endpoint><Endpoint path="/api/{version}/objects/documents/{doc_id}/versions/{major_version}/{minor_version}/annotation" method="POST"></Endpoint>The limits will vary depending upon the type of annotation:

* For Note, Link & Anchor Annotations, Subject (in Header) will be limited to 32,000 characters.

* For Note, Link, Line and Reply Annotations, Comment will be limited to 32,000 characters.

* For External Links, URL Length will be limited to 32,000 characters.

For items that exceed the limits when leveraging these endpoints, Vault automatically truncates the values to the associated limit.

</ReleaseNote>
<ReleaseNote id="23r2-blocking-nonunique-headers-to-prevent-data-loss" lr="23r1.2" app_family="platform" version="23r2">### Blocking Non-Unique Headers to Prevent Data Loss {#23r2-blocking-nonunique-headers-to-prevent-data-loss}

In this release, non-unique object field headers are blocked from being used in the following areas:

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

* [Update Multiple Documents](/vault-api/api-reference/23.2/documents/update-documents/update-multiple-documents)

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

* [Vault Loader](/vault-api/api-reference/23.2/vault-loader)

Prior to this release, non-unique headers were being ignored and failing silently. Going forward, these will be blocked and the API response will indicate `FAILURE` with details on which headers should be made unique.

</ReleaseNote>
<ReleaseNote id="23r2-override-checkout-option-for-state-change-document-operation-jobs" lr="23r1.2" app_family="platform" version="23r2">### Override Checkout Option for State Change Document Operation Jobs {#23r2-override-checkout-option-for-state-change-document-operation-jobs}

This feature adds a new attribute, `override_checkout_state_change`, to the `Changestatejobaction` component. When `true`, this attribute allows a job configured with a document state change action to proceed even when a minor version of the document is checked out. This functionality is only available when the configured Current State is the lifecyle’s configured steady state type and the `destination_state` is the lifecycle’s configured obsolete state type.

</ReleaseNote>
<ReleaseNote id="23r2-applicationspecific-endpoints" app_family="platform" version="23r2">### Application-Specific Endpoints {#23r2-applicationspecific-endpoints}

</ReleaseNote>
<ReleaseNote id="23r2-quality-qms-quality-teams-api" lr="23r1.3" app_family="platform" version="23r2">### Quality QMS: Quality Teams API {#23r2-quality-qms-quality-teams-api}

In Quality Vaults with QMS, the majority of record or work access and assignments are managed through Quality Teams. You can learn more about all of the functions available with [Quality Teams](https://quality.veevavault.help/en/lr/52842) in Vault Help. Prior to this release, team assignments have been supported only in the UI of Veeva QMS due to the highly controlled, often process-specific nature work assignments. This further implies that some operations, such as role changes in integrated systems, or work reassignments needed when an individual changes roles or leaves a company can be time consuming as they must be done through the vault UI on a record-by-record basis. In this release, we’re introducing public APIs to allow organizations to manage assignments within Quality Teams.

<Endpoint path="/app/quality/qms/teams/vobjects/{object_name}/actions/manageassignments" method="POST"></Endpoint>This new, bulk-enabled endpoint can accept a text or CSV file which describes the desired operations, including the addition or removal of users from team roles on records of the `{object_name}` specified in the endpoint URL. The endpoint returns a job ID, allowing for the user to [retrieve the job status](/vault-api/api-reference/23.2/jobs/retrieve-job-status). The actual team assignment updates are performed asynchronously by the system on behalf of the user, and in this initial release, respect Quality Team specific configurations which impact business logic such as:

* Minimum & maximum required assignments for team roles

* Constraining roles & user assignment eligibility

* Records in team assignment locked states

* New assignments must be for active users

* Exclusive role membership restrictions

* Team Completeness automation

* Active role-based task (re)assignment for new and removed users

Vault notifies the invoking user of the results of the call upon completion.

</ReleaseNote>
<ReleaseNote id="23r2-clinical-trigger-entry-action-milestone-creation-via-api" lr="23r1.3" app_family="platform" version="23r2">### Clinical: Trigger Entry Action Milestone Creation via API {#23r2-clinical-trigger-entry-action-milestone-creation-via-api}

his release introduces a new API endpoint called Execute Milestone Story Event. This feature is designed to support milestone creation for migrated records while minimizing system downtime and managing system performance. It includes a parameter to capture the object to be acted upon and accepts an optional VOF-standard `idParam` input to define alternative unique IDs.

<Endpoint path="/api/{version}/app/clinical/milestone/{object_name}/actions/applytemplate" method="POST"></Endpoint>The data input for this feature will be in CSV format, supporting a maximum of 500 data rows, plus a header row. Each row in the CSV input will define one object record ID, for which milestones will be created, and a single *Story Event* record to define what milestones will be created. All record IDs and *Story Events* must point to an active record at the same level as the `{object_name}` path parameter. This is particularly useful when a record is migrated into Vault in an advanced lifecycle state by providing an option to create any milestones that would normally be created by lifecycle state entry actions.

A series of synchronous validation checks will execute at runtime before any jobs are scheduled in Vault. If any validation checks fail, an error message is provided and no jobs are initiated or scheduled.

For every row in the CSV file, Vault will initiate a unique **Create Milestones from Template** job according to the `story_event__v`. As jobs complete, the API will return a success or failure result and job ID for each row.

</ReleaseNote>
<ReleaseNote id="23r2-rim-regulatoryone-edl-api" lr="23r1.2" app_family="platform" version="23r2">### RIM & RegulatoryOne: EDL API {#23r2-rim-regulatoryone-edl-api}

With v23.2, the [EDL API endpoints](/vault-api/api-reference/23.2/expected-document-lists) are enabled in RIM and RegulatoryOne Vaults by default. Prior to this release, some customers needed to contact Veeva Support to enable these endpoints in RIM and RegulatoryOne Vaults.

</ReleaseNote>

### Vault Loader {#23r2-vault-loader}

<ReleaseNote id="23r2-vault-loader-command-line-support-for-record-migration-mode-update-upsert" lr="23r1.2" app_family="platform" version="23r2">### Vault Loader Command Line Support for Record Migration Mode Update & Upsert {#23r2-vault-loader-command-line-support-for-record-migration-mode-update-upsert}

Vault Loader Command Line users can now leverage Record Migration Mode to update and upsert records to any state while bypassing reference constraints, validation rules, entry actions, and entry criteria.

Learn more about using Record Migration Mode with the Vault Loader Command Line in [Vault Help](https://platform.veevavault.help/en/lr/67332/#create-object-records).

</ReleaseNote>

## VQL {#vql}

<ReleaseNote id="23r2-vql-on-object-attachments" lr="23r1.3" app_family="platform" version="23r2">### VQL on Object Attachments {#23r2-vql-on-object-attachments}

Vault now supports querying object attachment metadata, including file version, filename, and MD5 checksum. Attachments are supported as subqueries on objects in the `SELECT` and `WHERE` clauses. Querying object attachments is supported on objects with attachments enabled and is not supported on objects with “Use Action security to control Attachments” enabled.

Learn more about [VQL for Vault object attachments](/vql/query-targets/attachments).

</ReleaseNote>
<ReleaseNote id="23r2-more-queryable-workflow-fields" lr="23r1.3" app_family="platform" version="23r2">### More Queryable Workflow Fields {#23r2-more-queryable-workflow-fields}

Workflow queries now support retrieving the [workflow configuration version](https://platform.veevavault.help/en/lr/5213/#version) (`workflow_definition_version__sys`). Additionally, workflow task queries now support retrieving the *Completed By* field (`completed_by__sys`) and *Participant Group* field (`participant_group__sys`). These fields are available for both active workflows and workflow tasks (`active_worklow__sys` and `active_workflow_task__sys`) and inactive workflows and workflow tasks (`inactive_workflow__sys` and `inactive_workflow_task__sys`).

</ReleaseNote>
<ReleaseNote id="23r2-display-format" lr="23r1.3" app_family="platform" version="23r2">### Display Format {#23r2-display-format}

Admins can now configure how text and number field values should be displayed in Vault using format masks.
This enhancement supports use cases for capturing phone numbers in text fields and percentages in number fields.

In API v23.2, [Query Describe](/vql/references/vql-api-headers#Query_Describe) in VQL includes a `format_mask` attribute for text and number fields.
A new VQL function, `TODISPLAYFORMAT()`, returns the formatted value of text fields, number fields, formula fields (where the return type is *Text* or *Number*), and lookup fields (that are looking up text or number field values). This function is not supported in `WHERE` clauses. By default, queries that do not use this function return the raw field value. Learn more about [TODISPLAYFORMAT()](/vql/functions-options/todisplayformat).

The Vault Java SDK returns the raw field value.

Learn more about format masks in [Vault Help](https://platform.veevavault.help/en/lr/15057#Format_Masks).

</ReleaseNote>
<ReleaseNote id="23r2-vql-for-job-history" lr="23r1.3" app_family="platform" version="23r2">### VQL for Job History {#23r2-vql-for-job-history}

SDK and VQL developers can now query all job history and related SDK job tasks by accessing new query targets: `job_history__sys` and `job_task__sys`.

Job history queries support filtering on:

* Job status

* Job metadata name

* Job name

* Job type

* Job title

* Schedule date

* Queue date

* Start DateTime

* Finish DateTime

Job task history queries support filtering on:

* Task ID

* Job instance ID

* Task status

* Job queue DateTime

* Start DateTime

* Finish DateTime

Learn more about [querying job histories and job task histories](/vql/query-targets/jobs).

</ReleaseNote>
<ReleaseNote id="23r2-function-name-in-query-describe" lr="23r1.3" app_family="platform" version="23r2">### Function Name in Query Describe {#23r2-function-name-in-query-describe}

Query Describe now includes the VQL function name when `X-VaultAPI-DescribeQuery=true` and the `SELECT` clause applies a function to a field. This shows developers that VQL has transformed the return data.

Learn more about [Query Describe](/vql/references/vql-api-headers#Query_Describe).

</ReleaseNote>
<ReleaseNote id="23r2-query-governor-concurrency-rules" lr="23r1.2" app_family="platform" version="23r2">### Query Governor: Concurrency Rules {#23r2-query-governor-concurrency-rules}

VQL now enforces a limit of five (5) queries *per user per Vault* for concurrent execution and processing. VQL will throttle additional query requests until existing queries have completed. This change applies to all API versions.

Learn more about [query performance](/vql/references/query-performance-best-practices) and [VQL transaction limits](/vql/references/system-limits-performance/transaction-limits).

</ReleaseNote>

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

<ReleaseNote id="23r2-global-changes" app_family="platform" version="23r2">### Global Changes {#23r2-global-changes}

</ReleaseNote>
<ReleaseNote id="23r2-audit-correct-user-for-sdk-trigger-updates" lr="23r1.3" app_family="platform" version="23r2">### Audit Correct User for SDK Trigger Updates {#23r2-audit-correct-user-for-sdk-trigger-updates}

When a user updates a record that executes an SDK trigger, Vault now logs “[SDK User] on behalf of [Current User]” in the audit trail to show that the change was automatic based on the user’s action. Prior to 23R2, the audit trail would show that the user performed the SDK action.

For example, prior to 23R2, the audit trail would show “[user@vault.com](mailto:user@vault.com)” performed the action, and with 23R2, the audit trail shows “System on behalf of [user@vault.com](mailto:user@vault.com)”.

</ReleaseNote>
<ReleaseNote id="23r2-connection-exception-management" lr="23r1.3" app_family="platform" version="23r2">### Connection Exception Management {#23r2-connection-exception-management}

To maintain Vault performance, *User Exception Messages* (`exception_message__sys`) and *User Exception Items* (`exception_item__sys`) have been migrated to HVO Objects and no longer support faceting in Vault UI. Additionally, records that have been marked as inactive or are older than 180 days will be purged from Vault on a nightly basis. Customers who wish to retain this data for longer periods are encouraged to use Scheduled Data Exports or Vault Loader to extract the data for storage outside of Vault.

</ReleaseNote>
<ReleaseNote id="23r2-sdk-debug-log-filters" lr="23r1.3" app_family="platform" version="23r2">### SDK Debug Log Filters {#23r2-sdk-debug-log-filters}

When creating SDK debug logs, Vault Admins and developers can now select additional options including Log Level and Class Filters. This allows for more granular control over what information is included in the logs and helps prevent hitting log limits when debugging. Log Level selection is inclusive of lower levels; for example, when the log level is set to WARN, debug logs will include warnings, errors, and exceptions. The default log level value is **ALL**. When Class Filters are applied, Vault will only capture log events from the selected class.The maximum number of class filters allowed is 10.

Learn more about SDK Debug Log Filters in [Vault Help](https://platform.veevavault.help/en/lr/14341/#debug_log).

</ReleaseNote>
<ReleaseNote id="23r2-syswrn-for-sdk-logs" lr="23r1.2" app_family="platform" version="23r2">### SYSWRN for SDK Logs {#23r2-syswrn-for-sdk-logs}

Vault now generates a new logtype, `SYSWRN`, when a system-level warning occurs (for example, Intelligent Record Update warnings). These log entries will be included in active [SDK Debug Logs](/vault-sdk/troubleshooting-runtime-errors/debug-log) and will be included in the [SDK Runtime Logs](/vault-sdk/troubleshooting-runtime-errors/runtime-log) when the log-level is set to *WARN*.

</ReleaseNote>
<ReleaseNote id="23r2-new-interfaces-methods" app_family="platform" version="23r2">### New Interfaces & Methods {#23r2-new-interfaces-methods}

</ReleaseNote>
<ReleaseNote id="23r2-object-lifecycle-metadata-actions-service" lr="23r1.3" app_family="platform" version="23r2">### Object Lifecycle Metadata & Actions Service {#23r2-object-lifecycle-metadata-actions-service}

This feature introduces Object Lifecycle Services to the Vault Java SDK. These include:

* `ObjectLifecycleMetadataService`

* `ObjectLifecycleStateUserActionMetadataService`

* `ObjectLifecycleStateUserActionService`

These services, which are located in the new `lifecycle` package, allow developers to retrieve configuration metadata of object lifecycles and actions, retrieve lifecycle information about object records, and execute user actions.

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

</ReleaseNote>
<ReleaseNote id="23r2-workflow-actions-service-sdk" lr="23r1.3" app_family="platform" version="23r2">### Workflow Actions Service SDK {#23r2-workflow-actions-service-sdk}

With v23.1.3, the Vault Java SDK now includes a Workflow Action Service to retrieve configuration metadata of workflows and information about workflow instances, as well as methods to execute actions on active workflows. These include:

* `getWorkflowStartMetadata()`

* `getWorkflowInstances()`

* `getWorkflowStartRequirements()`

* `getAvailableWorkflows()`

* `startWorkflow()`

* `cancelWorkflow()`

* `getWorkflowParticipants()`

* `getWorkflowItems()`

* `getWorkflowItems()`

The Vault Java SDK does not support legacy Document Workflows. Learn more about [Workflow Action Services](/vault-sdk/services/workflow-services/#Workflow_Action_Services).

</ReleaseNote>
<ReleaseNote id="23r2-object-field-metadata-service" lr="23r1.3" app_family="platform" version="23r2">### Object Field Metadata Service {#23r2-object-field-metadata-service}

This new service provides comprehensive access to field-type specific metadata for object fields. For example, developers can retrieve the maximum length for text fields and the minimum or maximum value for number fields.

</ReleaseNote>
<ReleaseNote id="23r2-remote-vault-information-service" lr="23r1.3" app_family="platform" version="23r2">### Remote Vault Information Service {#23r2-remote-vault-information-service}

Developers can now retrieve the Vault DNS, name, and ID of a remote Vault using an active Vault to Vault connection. This allows developers to construct notifications that guide a user to a remote Vault. Local and external Connections are not supported.

Learn more about [Vault Information Service](/vault-sdk/services/logservice-informationservice).

</ReleaseNote>
<ReleaseNote id="23r2-annotation-service-read-metadata" lr="23r1.4" app_family="platform" version="23r2">### Annotation Service: Read, Metadata {#23r2-annotation-service-read-metadata}

With Vault Java SDK v23.2, developers can leverage Document Viewer and Annotation (DVA) functions to retrieve information on all annotation types. This is enabled by two primary services (`AnnotationService` and `AnnotationMetadataService`), as well as three primary interfaces (`Annotation`, `AnnotationPlacemark`, and `AnnotationReference`).

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

</ReleaseNote>
<ReleaseNote id="23r2-existing-interfaces-methods" app_family="platform" version="23r2">### Existing Interfaces & Methods {#23r2-existing-interfaces-methods}

</ReleaseNote>
<ReleaseNote id="23r2-workflow-custom-actions-sdk-for-multi-record-object-workflows" lr="23r1.3" app_family="platform" version="23r2">### Workflow Custom Actions SDK for Multi Record Object Workflows {#23r2-workflow-custom-actions-sdk-for-multi-record-object-workflows}

With v23.1.3, the Vault Java SDK `RecordWorkflowAction` now supports document workflow actions (workflows on the `envelope__sys` object). Additionally, all workflow types now support record workflow actions on the start step and task step.

To support both object and document workflows, we've made changes to the workflow package in the Vault Java SDK. For example, in `RecordWorkflowActionContext` we've deprecated `getRecords()` for a new `getWorkflowItems()` method, and added two new interfaces for `WorkflowItemDocument` and `WorkflowItemRecord`.

This enhancement will enable customers to use custom actions to automate business processes.

</ReleaseNote>
<ReleaseNote id="23r2-object-reference-support-in-recordservice" lr="23r1.3" app_family="platform" version="23r2">### Object Reference Support in RecordService {#23r2-object-reference-support-in-recordservice}

`RecordService` now supports setting object reference fields using any unique fields on the referring object. Previously, developers were limited to using the ID field.

</ReleaseNote>
<ReleaseNote id="23r2-query-limits" lr="23r1.3" app_family="platform" version="23r2">### Query Limits {#23r2-query-limits}

With v23.1.3, the Vault Java SDK Query Service now enforces limits on search terms to ensure optimal performance:

* 250 characters for individual search terms

* 225,000 characters for the complete query

For API v23.2, the 250 character limit on individual search terms also applies. The API already enforces a limit of 50,000 characters on a given API call.

Learn more about [Query Service](/vault-sdk/services/query-service). Learn more about [searching Vault on Vault Help](https://platform.veevavault.help/en/lr/442).

</ReleaseNote>
<ReleaseNote id="23r2-picklist-name-in-sdk" lr="23r1.2" app_family="platform" version="23r2">### Picklist Name in SDK {#23r2-picklist-name-in-sdk}

A new method, `getName`, has been added to the `Picklist` and `PicklistValue` interfaces. This allows developers access to the API name of the picklist or picklist value.

Learn more in the [Javadocs](https://repo.veevavault.com/javadoc/vault-sdk-api/23.1.2/docs/api/com/veeva/vault/sdk/api/picklist/Picklist.html).

</ReleaseNote>
<ReleaseNote id="23r2-retrieve-job-name-for-sdk-jobs" lr="23r1.2" app_family="platform" version="23r2">### Retrieve Job Name for SDK Jobs {#23r2-retrieve-job-name-for-sdk-jobs}

This feature introduces a new method, `getJobName`, to the `JobContext` interface. This method allows SDK developers to retrieve the corresponding SDK job name.

Learn more in the [Javadocs](https://repo.veevavault.com/javadoc/vault-sdk-api/23.1.2/docs/api/com/veeva/vault/sdk/api/job/JobContext.html).

</ReleaseNote>
<ReleaseNote id="23r2-job-owner-for-ad-hoc-sdk-jobs" lr="23r1.2" app_family="platform" version="23r2">### Job Owner for ad hoc SDK Jobs {#23r2-job-owner-for-ad-hoc-sdk-jobs}

Developers can now set the Job Owner for ad hoc (non-scheduled) SDK Jobs. The owner can be set to either the `INITIATING_USER` or the `REQUEST_OWNER`. This allows developers to control how the custom code for the SDK Job will execute.

Learn more in the [Javadocs](https://repo.veevavault.com/javadoc/vault-sdk-api/23.1.2/docs/api/com/veeva/vault/sdk/api/job/JobParameters.html).

</ReleaseNote>
<ReleaseNote id="23r2-applicationspecific-interfaces-methods" app_family="platform" version="23r2">### Application-Specific Interfaces & Methods {#23r2-applicationspecific-interfaces-methods}

</ReleaseNote>
<ReleaseNote id="23r2-sdk-entry-point-for-coa-email-intake-to-vault" lr="23r1.3" app_family="platform" version="23r2">### SDK Entry Point for COA Email Intake to Vault {#23r2-sdk-entry-point-for-coa-email-intake-to-vault}

For this release, QualityOne introduces a new Vault Java SDK entry point that allows users to process incoming information when Vault receives an email and its attachments from external parties using the [Automated COA Email Intake feature](https://qualityone.veevavault.help/en/lr/69952/#about-email-intake). After processing the incoming email’s information, the email intake feature creates the applicable COA Inspection records based on how developers customize the SDK entry point.

</ReleaseNote>