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

# Vault Developer Release Notes

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

## Developer Features in 21R3 {#developer-features-in-21r3}

We are pleased to bring you the following additions and enhancements to Developer Portal features in 21R3. REST API features added in 21R3 only affect API v21.3, unless otherwise noted.

## Service Announcements {#service-announcements}

<ReleaseNote id="21r3-spark-message-reverse-ip-lookup-change" lr="21r2.4" app_family="platform" version="21r3">### Spark Message Reverse IP Lookup Change {#21r3-spark-message-reverse-ip-lookup-change}

Outbound Spark messages are now sent from an IP address associated with Veeva Vault. Developers and network engineers can apply network and firewall rules by allowlisting `*.veevavault.com`. Customers who are currently allow listing by domain will need to update their rules to support `*.veevavault.com` domains. Learn more in the [Vault Java SDK Documentation](/vault-sdk/sdk-integrations/spark-messaging/message-delivery-allowlist).

</ReleaseNote>

## Global Changes {#global-changes}

<ReleaseNote id="21r3-envelope-objects-to-high-volume-object" lr="21r2.3" app_family="platform" version="21r3">### Envelope Objects to High Volume Object {#21r3-envelope-objects-to-high-volume-object}

Vault Platform objects *Envelope* and *Envelope Contents* (`envelope__sys`), which are used to represent Vault workflows on documents, are moving to high volume to deliver performance and scalability for workflows. The `data_store` attribute for these objects is set to `high_volume`.

These objects will no longer support Sharing Settings and record-level access control. High volume objects are supported in queries and APIs only in version v20.3+. Customers querying these two objects must use version v20.3+.

</ReleaseNote>
<ReleaseNote id="21r3-deprecating-vaultwide-document-migration-mode" lr="21r2.4" app_family="platform" version="21r3">### Deprecating Vault-wide Document Migration Mode {#21r3-deprecating-vaultwide-document-migration-mode}

After the 21R3 release, Vault-wide Document Migration Mode will be deprecated.

Instead, use the `X-VaultAPI-MigrationMode` API header with the Vault REST API’s [Create Multiple Documents](/vault-api/api-reference/21.3/documents/create-documents/create-multiple-documents), [Create Multiple Document Versions](/vault-api/api-reference/21.3/documents/update-documents/create-multiple-document-versions), [Update Multiple Documents](/vault-api/api-reference/21.3/documents/update-documents/update-multiple-documents), and [Add Multiple Document Renditions](/vault-api/api-reference/21.3/documents/document-renditions/add-multiple-document-renditions) endpoints, or use Vault Loader with the Document Migration Mode checkbox selected. These methods minimize risk and end-user impact by ensuring that only the documents being created and updated in the API request are subject to migration mode limitations, allowing the rest of the Vault to remain fully operational.

</ReleaseNote>

## REST API v21.3 {#rest-api-v213}

### New Endpoints {#21r3-new-endpoints}

<ReleaseNote id="21r3-hvo-online-alter-via-mdl" lr="21r2.3" app_family="platform" version="21r3">### HVO Online Alter via MDL {#21r3-hvo-online-alter-via-mdl}

With this feature, Administrators can alter the metadata of a high volume object with greater than 10,000 records without locking the system. This allows end users to continue to use the system as normal during high volume object alteration. This functionality is not available in the Vault UI.

API users can execute this type of HVO online alter from the Execute MDL Script Asynchronously endpoint:

<Endpoint path="/api/mdl/execute_async" method="POST"></Endpoint>Additionally, API users can cancel HVO online alters before the final stages of deployment with the following endpoint:

<Endpoint path="/api/{version}/metadata/vobjects/{object_name}/actions/canceldeployment" method="POST"></Endpoint>HVO online alters are executed as a Job. Users can poll the Job Status endpoint to monitor for job completion, and after the Job is complete, the following endpoint can retrieve the deployment results:

<Endpoint path="/api/mdl/execute_async/{job_id}/results" method="GET"></Endpoint></ReleaseNote>
<ReleaseNote id="21r3-session-keep-alive" lr="21r2.4" app_family="platform" version="21r3">### Session Keep Alive {#21r3-session-keep-alive}

Developers are now able to keep a Vault API session alive with a light-weight endpoint that returns `SUCCESS` when given a valid Session ID. If given an invalid Session ID, Vault returns `INVALID_SESSION_ID`.Vault still enforces the 48-hour maximum session duration even when used with the Session Keep Alive.

<Endpoint path="/api/{version}/keep-alive" method="POST"></Endpoint>View this endpoint in the [v21.3 API Reference](/vault-api/api-reference/21.3/authentication/session-keep-alive).

</ReleaseNote>
<ReleaseNote id="21r3-email-participants-action" lr="21r2.3" app_family="platform" version="21r3">### Email Participants Action {#21r3-email-participants-action}

Workflow users can now send emails to participants in an active workflow by using *Email Participants* action. The new `emailparticipants` action is available to retrieve and execute with the Vault API:

<Endpoint path="/api/{version}/objects/objectworkflows/{workflow_id}/actions/emailparticipants" method="POST"></Endpoint>To email participants via API, developers must provide the list of participants, the message, and whether the email will be copied to the sending user.

</ReleaseNote>

### Existing Endpoints {#21r3-existing-endpoints}

<ReleaseNote id="21r3-read-understood-workflows-restrict-task-completion-by-delegate-users" lr="21r2.2" app_family="platform" version="21r3">### Read & Understood Workflows: Restrict Task Completion by Delegate Users {#21r3-read-understood-workflows-restrict-task-completion-by-delegate-users}

With this release, delegated users cannot complete Read & Understood workflow tasks in the new Read & Understood workflows released in 21R2 General Release. This matches the behavior of our legacy Read & Understood workflows. This change affects all versions of the API.

</ReleaseNote>
<ReleaseNote id="21r3-on-behalf-of-auditing-export-enhancements" lr="21r2.2" app_family="platform" version="21r3">### On Behalf Of Auditing Export Enhancements {#21r3-on-behalf-of-auditing-export-enhancements}

With this release, audit entries that contain *on behalf of* will now have a new `on_behalf_of` field populated when returning CSV and JSON. The existing User Name column will contain the user on the left side of *on behalf of* while a new column “On Behalf Of” will contain the user on the right side. Previously the two users were concatenated into the User Name column. Note that not all System actions are included in these changes.

View this endpoint in the [v21.3 API Reference](/vault-api/api-reference/21.3/logs/audit/retrieve-audit-details).

</ReleaseNote>
<ReleaseNote id="21r3-audit-response-offset-value-always-begins-at-0" lr="21r2.2" app_family="platform" version="21r3">### Audit Response Offset Value Always Begins at 0 {#21r3-audit-response-offset-value-always-begins-at-0}

When calling the API for individual object record audit logs, `0` will always be returned as the initial offset value.

<Endpoint path="/api/{version}/vobjects/{object_name}/{object_record_id}/audittrail" method="GET"></Endpoint>The change affects all versions of the API. Prior to this release, certain scenarios resulted in 200 being returned as the initial offset value.

View this endpoint in the [v21.3 API Reference](/vault-api/api-reference/21.3/logs/audit-history/retrieve-complete-audit-history-for-a-single-object-record).

</ReleaseNote>
<ReleaseNote id="21r3-workflow-cancellation-comment" lr="21r2.3" app_family="platform" version="21r3">### Workflow Cancellation Comment {#21r3-workflow-cancellation-comment}

Workflow administrators can require comments on the cancellation of an active workflow. If a workflows requires a cancellation comment, API users can provide this comment with the new `cancellation_comment` parameter on the existing cancel API.

<Endpoint path="/api/{version}/objects/objectworkflows/{workflow_id}/actions/cancel?cancellation_comment={cancellation comment}" method="POST"></Endpoint></ReleaseNote>
<ReleaseNote id="21r3-single-verdict-any-lifecycle-workflow" lr="21r2.2" app_family="platform" version="21r3">### Single Verdict: Any Lifecycle Workflow {#21r3-single-verdict-any-lifecycle-workflow}

*Any Lifecycle* document workflows now support Single Verdict. Users can provide a single verdict to all documents in the workflow.

To complete a single verdict task in an Any Lifecycle workflow, you must use the [Initiate Workflow Task Action](/vault-api/api-reference/21.3/object-lifecycle-workflows/workflow-tasks/initiate-workflow-task-action) endpoint in REST API v21.3+.

</ReleaseNote>
<ReleaseNote id="21r3-set-tokens-in-instructions" lr="21r2.3" app_family="platform" version="21r3">### Set Tokens In Instructions {#21r3-set-tokens-in-instructions}

Workflow administrators can add their own tokens in Instructions at the *Start* and *Task* steps of the workflow.

Workflows on documents support Tokens `${docName}` and `${docNumber}`. This gives the name and number of the document if there is a single document in the workflow.

Workflows on objects support object field tokens for all field types, except *Long Text* and *Rich Text* fields.

This feature also allows administrators to configure no link tokens `{workflowContentsNoLink}` and `${workflowTargetNoLink}` for Notification Subject.

</ReleaseNote>
<ReleaseNote id="21r3-delete-document-relationships-on-older-versions" lr="21r2.3" app_family="platform" version="21r3">### Delete Document Relationships On Older Versions {#21r3-delete-document-relationships-on-older-versions}

With this feature, users can delete a relationship on an older version of the document where the relationship is version specific with *Edit Relationship* permission. Previously, users could not delete a relationship on an older version of the document where the relationship is version specific. Users can delete a relationship either via UI or API.

To delete a relationship on an older, version-specific document with the API, you can use the following endpoint:

<Endpoint path="/api/{version}/objects/documents/{doc_id}/versions/{major_version}/{minor_version}/relationships/{relationship_id}" method="DELETE"></Endpoint></ReleaseNote>
<ReleaseNote id="21r3-allowed-users-when-assigning-new-document-owner" lr="21r2.3" app_family="platform" version="21r3">### Allowed Users When Assigning New Document Owner {#21r3-allowed-users-when-assigning-new-document-owner}

Before 21R2.3, Vault did not restrict which users could be assigned as a new document owner (through manual assignment, bulk actions, or the REST API). Starting from this release, Admins can configure the Owner lifecycle role to restrict who can be assigned as the new document owner. This feature does not impact the document creation flow, where the creator is automatically assigned as the document owner.

In addition to the UI, the following APIs honor this new validation when assigning a new owner on a document:

<Endpoint path="/api/{version}/objects/documents/{id}/roles" method="POST"></Endpoint><Endpoint path="/api/{version}/objects/documents/roles/batch" method="POST"></Endpoint>As the allowed users default to “All users and groups” at upgrade time, there is no API behavior change without configuration.

</ReleaseNote>
<ReleaseNote id="21r3-protected-pdf-renditions" lr="21r2.4" app_family="platform" version="21r3">### Protected PDF Renditions {#21r3-protected-pdf-renditions}

With this release, Vault allows PDF viewable rendition downloads with safeguards applied which restrict alterations to the downloaded rendition. For users who have appropriate security permissions, we’ve added a new parameter, `protectedRendition`, to the [Download Document Rendition File](/vault-api/api-reference/21.3/documents/document-renditions/download-document-rendition-file) and the [Download Document Version Rendition File](/vault-api/api-reference/21.3/documents/document-renditions/download-document-version-rendition-file) endpoints to request a PDF rendition without PDF protection applied.

</ReleaseNote>
<ReleaseNote id="21r3-tab-mdl-component-new-id-attribute" lr="21r2.3" app_family="platform" version="21r3">### Tab MDL Component: New [id] Attribute {#21r3-tab-mdl-component-new-id-attribute}

When retrieving `Tab` component records, the Vault REST API’s [Retrieve Component Record Collection](/vault-api/api-reference/21.3/vault-query-language-vql) and [Retrieve Component Record(XML/JSON)](/vault-api/api-reference/21.3/document-lifecycle/lifecycle-role-assignment-rules/delete-override-rulescomponent-record-xml-json) endpoints now return a new `id`  in the `Tab` component description. Developers can use the `id` to construct a URL that navigates to a tab. The `id` attribute is read-only and is not used in MDL `CREATE` or `RECREATE`commands.

</ReleaseNote>
<ReleaseNote id="21r3-audit-trail-new-entries-for-vault-object-updates-that-dont-change-data-values" lr="21r3.0" app_family="platform" version="21r3">### Audit Trail: New Entries for Vault Object Updates that Don’t Change Data Values {#21r3-audit-trail-new-entries-for-vault-object-updates-that-dont-change-data-values}

The [Retrieve Complete Audit History for a Single Object Record](/vault-api/api-reference/21.3/logs/audit-history/retrieve-complete-audit-history-for-a-single-object-record) endpoint now returns a `"{field label}" updated sort order` object audit trail entry when multi-value picklist selections are reordered, as well as a `Record saved with no changes` entry when users save records with no data changes. The latter case can occur when a user modifies data on an object record, but then reverts the change and saves the record. Please note this feature will be made available in the Dec 3 release, but will not be available in pre-release or limited release Vaults.

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

</ReleaseNote>
<ReleaseNote id="21r3-clinical-milestone-edl-endpoint-enhancements" lr="21r2.4" app_family="platform" version="21r3">### Clinical Milestone & EDL Endpoint Enhancements {#21r3-clinical-milestone-edl-endpoint-enhancements}

There is a new parameter, `applyWhereEDLItemsExist`, on the existing Create EDLs endpoint. When that parameter is set to `true`, the Create EDL job will be applied to existing EDLs, so that EDL items can be created from EDL Item Template records not previously used.

The new Recalculate Milestones endpoint accepts a CSV of document IDs and forces recalculation of the *Milestone* field on each of those documents.

<Endpoint path="/api/version/objects/documents/milestones/actions/recalculate" method="POST"></Endpoint></ReleaseNote>
<ReleaseNote id="21r3-rim-copy-into-content-plan-api" lr="21r2.2" app_family="platform" version="21r3">### RIM: Copy into Content Plan API {#21r3-rim-copy-into-content-plan-api}

A new API endpoint is available to initiate the *Copy Into Content Plan* action via the Vault REST API.

<Endpoint path="/api/{version}/app/rim/content_plans/actions/copyinto" method="POST"></Endpoint>This will copy a Content Plan Item or a Content Plan section and its descendants from one Content Plan to another Content Plan. The action will be synchronous for copying a single Content Plan Item, and asynchronous for copying at the Content Plan section level.

View this endpoint in the [v21.3 API Reference](/vault-api/api-reference/21.3/vault-query-language-vql).

</ReleaseNote>
<ReleaseNote id="21r3-veeva-sitevault-user-administration-api" lr="21r2.3" app_family="platform" version="21r3">### Veeva SiteVault: User Administration API {#21r3-veeva-sitevault-user-administration-api}

These new Veeva SiteVault-specific endpoints allow API users to manage user administration in a Veeva SiteVault that uses the Extensible Permissions feature (added 21R2):

* Retrieve a user’s current permissions for a research organization and all sites in the research organization

* Update a user’s permissions for a research organization and all sites in the research organization

* Add new users to a research organization and one or more sites in the research organization

For Veeva SiteVaults that are not using Extensible Permissions, existing Veeva Vault APIs should continue to be used.

</ReleaseNote>
<ReleaseNote id="21r3-veeva-safety-intake-json-api-for-safety-customers" lr="21r2.3" app_family="platform" version="21r3">### Veeva Safety: Intake JSON API for Safety Customers {#21r3-veeva-safety-intake-json-api-for-safety-customers}

Veeva Safety can now ingest calls from the Safety Intake JSON endpoint to receive an Inbox Item from a JSON file:

<Endpoint path="/api/{version}/app/safety/ai/intake" method="POST"></Endpoint>Vaults no longer require Safety.AI to receive calls from this endpoint. Vaults without Safety.AI only support processing structured data (JSON). The system ignores unstructured data.

</ReleaseNote>
<ReleaseNote id="21r3-veeva-safety-intake-api-using-json-object" lr="21r2.4" app_family="platform" version="21r3">### Veeva Safety: Intake API Using JSON Object {#21r3-veeva-safety-intake-api-using-json-object}

The Intake JSON endpoint now accepts JSON passed through as text in the request body.

To support this capability, two new body requests can be used in addition to the existing one:

* `multipart/form-data`: To pass JSON text in the `intake_json` parameter when passing another document in the `intake_form` parameter

* `application/json`: To only pass JSON text as raw content

</ReleaseNote>

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

<ReleaseNote id="21r3-email-to-vault" lr="21r2.3" app_family="platform" version="21r3">### Email to Vault {#21r3-email-to-vault}

With this feature,developers can define a Vault owned email address and configure processing behavior in the Admin UI. Incoming emails are converted into Email object records and are accessible in the new `EmailProcessor` SDK extension,. Developers can inspect the email metadata, content, and attachments and create documents and object records using existing SDK Services.

Learn more about [Email Processors](/vault-sdk/entry-points/email-processors).

</ReleaseNote>
<ReleaseNote id="21r3-workflow-cancellation-actions" lr="21r2.3" app_family="platform" version="21r3">### Workflow Cancellation Actions {#21r3-workflow-cancellation-actions}

Workflow administrators can configure Cancellation Actions, which are actions that get executed on the cancellation of an active workflow. In addition to Vault platform cancellation actions, developers can add their own custom `RecordAction` or `DocumentAction` for workflow cancellation of an object or document workflow using the Vault Java SDK.

There is a new `Usage` Enum value called `WORKFLOW_CANCEL`. Any document or record action with this Enum value can be configured as a cancellation action.

</ReleaseNote>
<ReleaseNote id="21r3-vaultinformationservice" lr="21r2.3" app_family="platform" version="21r3">### VaultInformationService {#21r3-vaultinformationservice}

This feature allows SDK developers to access basic configuration information for the local Vault, including the Vault ID, DNS, and name.

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

</ReleaseNote>
<ReleaseNote id="21r3-local-connectioncontext-for-connectionservice" lr="21r2.3" app_family="platform" version="21r3">### Local ConnectionContext for ConnectionService {#21r3-local-connectioncontext-for-connectionservice}

This feature introduces a new method, `newLocalConnectionContext`, to `ConnectionService`. This method allows developers to create a local connection context without needing a Local Connection record. The local connection context executes as the authenticated user and is not supported when SDK code is initiated by *System* (workflows and jobs).

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

</ReleaseNote>
<ReleaseNote id="21r3-queryservice-support-for-additional-targets" lr="21r2.3" app_family="platform" version="21r3">### QueryService Support for Additional Targets {#21r3-queryservice-support-for-additional-targets}

`QueryService` now supports the following query targets including relationships: `doc_role__sys`, `group__sys`, `group_memberships__sys`, and all non-legacy workflow query targets.

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

</ReleaseNote>
<ReleaseNote id="21r3-enhancements-to-json-binding-annotations" lr="21r2.2" app_family="platform" version="21r3">### Enhancements to JSON Binding Annotations {#21r3-enhancements-to-json-binding-annotations}

User-defined models now support extending other user-defined models, allowing developers to create models with inherited user-defined properties. For example, an `APIQueryResponse` model could extend an `APIResponse` model. Additionally, developers can define default values for user-defined properties for the following types: BigDecimal, Boolean, String, and collections of String. Learn more about [user-defined models](/vault-sdk/shared-code/udm).

</ReleaseNote>
<ReleaseNote id="21r3-enhancements-to-jsonservice" lr="21r2.3" app_family="platform" version="21r3">### Enhancements to JsonService {#21r3-enhancements-to-jsonservice}

This feature allows developers to create a new `JsonArrayBuilder` from an existing `JsonArray` or a new `JsonObjectBuilder` from an existing `JsonObject`. Additionally, developers can retrieve the names and types of each `JsonProperty` in a `JsonObject`.

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

</ReleaseNote>

## VQL {#vql}

<ReleaseNote id="21r3-standardize-escape-sequence-for-special-characters" lr="21r2.3" app_family="platform" version="21r3">### Standardize Escape Sequence for Special Characters {#21r3-standardize-escape-sequence-for-special-characters}

This feature standardizes the VQL escape character (`\`) and allows developers to reference supported special characters on all document fields, object fields, and other VQL endpoints. The supported list of characters includes: backslash (`\\`), carriage return (`\r`), double quote (`\"`), line feed (`\n`), percent sign (`\%`), single quote (`\'`), asterisk (`\*`), and tab (`\t`). The escape sequence has been standardized across all VQL functions and clauses and only impacts v21.3 and higher.

</ReleaseNote>

## MDL {#mdl}

<ReleaseNote id="21r3-update-task-due-date-on-object-date-field-update" lr="21r2.3" app_family="platform" version="21r3">### Update Task Due Date on Object Date Field Update {#21r3-update-task-due-date-on-object-date-field-update}

Workflow administrators can update the task due date based on an Object date field automatically when the date field is updated.

There is a new MDL attribute in Task due date based on the date field called `updateonfieldchange`, as shown below. This attribute is `false` by default but for tasks that automatically update based on date field change of value, this is set to `true`.

`<vwf:datefield type="object_field" datefieldvalue="object__c.due_date__c" updateonfieldchange="true" />`

</ReleaseNote>
<ReleaseNote id="21r3-document-reference-field-constraints" lr="21r2.4" app_family="platform" version="21r3">### Document Reference Field Constraints {#21r3-document-reference-field-constraints}

Vault can now constrain document reference fields on objects based on types, subtypes, and classifications, or based on values of other object fields. This can help narrow documents available for selection to those tailored for the purpose of the document reference field.

</ReleaseNote>
<ReleaseNote id="21r3-vault-quality-recurrence-check-for-complaints" lr="21r2.3" app_family="platform" version="21r3">### Vault Quality: Recurrence Check for Complaints {#21r3-vault-quality-recurrence-check-for-complaints}

With this feature, API users can create Quality Record Checks for Complaints through MDL using the `Qualityrecordcheck` component.

Learn more about [Quality Record Checks](/mdl/component-reference/component-types/qualityrecordcheck).

</ReleaseNote>
<ReleaseNote id="21r3-vault-quality-display-key-quality-team-roles-for-filtering-reporting" lr="21r2.3" app_family="platform" version="21r3">### Vault Quality: Display key Quality Team Roles for Filtering, Reporting {#21r3-vault-quality-display-key-quality-team-roles-for-filtering-reporting}

To support the surfacing of key Team Role assignments for Quality Team enabled records as user fields, this feature adds the `linked_field` attribute to the `Qualityteamrole` subcomponent type. This attribute may be set to any *User Object Reference Field* on the Team’s Object/Object type, provided the maximum number of allowed users in the `Qualityteamrole` is equal to 1.

For a given `Qualityteamrole`, if linked_field is configured, Vault updates the identified user field whenever the membership of the `Qualityteamrole` on a given record is updated, and users are no longer able to edit that field. If omitted, the default value is null.

Learn more about [linked role fields in Vault Help](https://quality.veevavault.help/en/lr/54508#linked-fields).

</ReleaseNote>
<ReleaseNote id="21r3-veeva-qms-create-related-record-entry-action" lr="21r2.4" app_family="platform" version="21r3">### Veeva QMS: Create Related Record Entry Action {#21r3-veeva-qms-create-related-record-entry-action}

To support Create Related Record entry actions, we've added the `Relatedrecordsetup` component type. Learn more in the [Component Type Reference](/mdl/component-reference/component-types/relatedrecordsetup).

</ReleaseNote>