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

# Vault Developer Release Notes

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

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

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

## Service Announcements {#service-announcements}

<ReleaseNote id="21r2-deprecate-public-ios-sdk" lr="21r1.4" app_family="platform" version="21r2">### Deprecate Public iOS SDK {#21r2-deprecate-public-ios-sdk}

The Vault Mobile iOS SDK has been deprecated and will no longer be updated or made available for download. Existing solutions built using this SDK will continue to work and must be maintained by the developer.

</ReleaseNote>

### Deprecating Vault-Wide Document Migration Mode {#deprecating-vault-wide-document-migration-mode}

In 20R2, we released the `X-VaultAPI-MigrationMode` API header to replace Vault-wide Document Migration Mode, which was never intended for use in live customer Vaults. In accordance with this, we’ve updated Vault Loader and Vault Certified Migration Partner tools  to use the API header. In 21R2, Veeva Support will no longer enable Document Migration Mode for customers. In 21R3, we will deprecate Vault-wide Document Migration Mode completely, meaning that Vaults where Document Migration Mode is currently enabled will revert to normal behavior.
Enabling Document Migration Mode for an entire Vault has an effect on all users and prevents many Vault processes from operating. Instead, use the `X-VaultAPI-MigrationMode` API header with the Vault REST API’s [Create Multiple Documents](/vault-api/api-reference/21.1/documents/create-documents/create-multiple-documents), [Create Multiple Document Versions](/vault-api/api-reference/21.2/documents/update-documents/create-multiple-document-versions), [Update Multiple Documents](/vault-api/api-reference/21.2/documents/update-documents/update-multiple-documents), and [Add Multiple Document Renditions](/vault-api/api-reference/21.2/documents/document-renditions/add-multiple-document-renditions) endpoints, or use Vault Loader with the **Document Migration Mode** checkbox. This minimizes risk and impact by ensuring that only the documents being created and updated in the API request are subject to migration mode limitations, and allows the rest of the Vault to be fully operational.

#### Access Permissions Change for Inbound Package Objects {#access-permissions-change-for-inbound-package-objects}

*Release Dates:*

* *Limited Release Customers: 21R1.3; June 4, 2021*

* *General Release Customers: 21R2.0; August 6, 2021*
Users now require the *Migration Packages: Deploy* permission in addition to object read permissions to read the following objects through the API or with VQL:

* `vault_package__v`: Inbound Package

* `vault_package_data__v`:  Inbound Package Data

* `vault_package_code__sys`: Inbound Package Code
This feature provides consistency with permissions in the Vault UI. If your integration queries these objects, you must update your integration user with the appropriate permissions. Note that Vault Owner and System Administrator security profiles are enabled with *Migration Packages: Deploy* permissions by default.

## Global Changes {#global-changes}

<ReleaseNote id="21r2-admins-can-edit-all-picklist-labels-picklist-value-labels" lr="21r1.3" app_family="platform" version="21r2">### Admins Can Edit All Picklist Labels & Picklist Value Labels {#21r2-admins-can-edit-all-picklist-labels-picklist-value-labels}

Standard picklist labels and picklist value labels can now be updated in admin and via API and MDL.

</ReleaseNote>
<ReleaseNote id="21r2-display-the-unclassified-doc-type-in-admin" lr="21r1.3" app_family="platform" version="21r2">### Display the Unclassified Doc Type in Admin {#21r2-display-the-unclassified-doc-type-in-admin}

The *Unclassified* document type (labeled as *Undefined* in previously created Vaults) is now a child of the *Base Document* type and visible in the Vault Admin UI. You can assign fields and document type groups to the *Unclassified* document types, and can also create document permissions on the document type. Note that required fields are not enforced while a document remains in the *Unclassified* document type (or the *Inbox* lifecycle).

Learn more about [configuring document types in the Vault Admin UI in Vault Help](https://platform.veevavault.help/en/lr/618).

</ReleaseNote>
<ReleaseNote id="21r2-relabel-undefined-document-type-to-unclassified" lr="21r1.3" app_family="platform" version="21r2">### Relabel “Undefined” Document Type to “Unclassified” {#21r2-relabel-undefined-document-type-to-unclassified}

In Vaults created after 21R2, the *Undefined* document type is relabeled as *Unclassified*. In Vaults that use Veeva Snap or custom integrations with the Vault REST API, relabeling the *Undefined* document type may cause errors when uploading documents. Check your integrations before updating this label. We recommend that customers experiencing errors change the label back to *Undefined* until this issue is resolved.

</ReleaseNote>
<ReleaseNote id="21r2-relabel-unclassified-lifecycle-to-inbox" lr="21r1.3" app_family="platform" version="21r2">### Relabel "Unclassified" Lifecycle to "Inbox" {#21r2-relabel-unclassified-lifecycle-to-inbox}

In Vaults created after 21R2, the *Unclassified* document lifecycle is relabeled as *Inbox*. In Vaults that use Veeva Snap or custom integrations with the Vault REST API, relabeling the *Unclassified* document lifecycle may cause errors when uploading documents. Check your integrations before updating this label. We recommend that customers experiencing errors change the label back to *Unclassified* until this issue is resolved.

</ReleaseNote>

## REST API v21.2 {#rest-api-v212}

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

<ReleaseNote id="21r2-promote-to-production" lr="21r1.4" app_family="platform" version="21r2">### Promote to Production {#21r2-promote-to-production}

With this feature, Vault Admins can promote a pre-production Vault to a production Vault directly from the Vault API. This enhances the self-service model of sandboxing by allowing Vault Admins to fully manage a Vault's lifecycle from initial to go-live.

<Endpoint path="/api/{version}/objects/sandbox/actions/buildproduction" method="POST"></Endpoint><Endpoint path="/api/{version}/objects/sandbox/actions/promoteproduction" method="POST"></Endpoint>View these endpoints in the [v21.2 API Reference](/vault-api/api-reference/21.2/sandbox-vaults/pre-production-vaults).

</ReleaseNote>

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

<ReleaseNote id="21r2-auth-change-my-password-user-credentials-as-body-parameters" lr="21r1.2" app_family="platform" version="21r2">### Auth & Change My Password: User Credentials as Body Parameters {#21r2-auth-change-my-password-user-credentials-as-body-parameters}

Starting from v21.2, the **Authentication** and **Change My Password** REST APIs ignore user credentials passed as query String parameters. These APIs only accept the `username` and `password` as body parameters. In previous API versions, we recommend using the body for these parameters as a best practice.

</ReleaseNote>
<ReleaseNote id="21r2-read-and-understood-document-workflows" lr="21r1.3" app_family="platform" version="21r2">### Read and Understood Document Workflows {#21r2-read-and-understood-document-workflows}

This feature allows administrators to create and run “Read and Understood” workflows for multiple documents.

Read and Understood workflows can’t be started using the Document Workflow APIs(formerly multi-document workflow), however, Read and Understood tasks can be completed, reassigned, or canceled using the Initiate Workflow Action APIs.

<Endpoint path="/api/{version}/objects/objectworkflows/{workflow_id}/actions" method="GET"></Endpoint><Endpoint path="/api/{version}/objects/objectworkflows/{workflow_id}/actions/{workflow_action}" method="GET"></Endpoint><Endpoint path="/api/{version}/objects/objectworkflows/{workflow_id}/actions/{workflow_action}" method="POST"></Endpoint>When querying Read and Understood workflow tasks, the Retrieve Workflow Tasks and Retrieve Workflow Task Details endpoints now include the `workflow_class__sys` field in the response with a value of `read_and_understood__sys`.

<Endpoint path="/api/{version}/objects/objectworkflows/tasks" method="GET"></Endpoint><Endpoint path="/api/{version}/objects/objectworkflows/tasks/{task_id}" method="GET"></Endpoint>Learn more in the [v21.2 API Reference](/vault-api/api-reference/21.2/object-lifecycle-workflows/workflow-tasks/retrieve-object-workflow-tasks).

</ReleaseNote>
<ReleaseNote id="21r2-restrict-document-workflow-to-a-single-document" lr="21r1.2" app_family="platform" version="21r2">### Restrict Document Workflow to a Single Document {#21r2-restrict-document-workflow-to-a-single-document}

We are adding some new attributes as part of this feature for Object and Document(formerly multi-document workflow) workflows.

Attribute `type` is getting added with all workflows. This will determine whether a workflow is Object or Document (formerly multi-document workflow) workflow.

Attribute `cardinality` determines whether you can have only one or many documents. For e.g.

<Endpoint path="/api/{version}/objects/documents/actions/{workflow_name}" method="GET"></Endpoint>will return type as `Document` and `cardinality` as `One` if it’s a Document workflow and can be used with only one document.

Learn more in the [v21.2 API Reference](/vault-api/api-reference/21.2/document-workflows/retrieve-all-document-workflows).

</ReleaseNote>
<ReleaseNote id="21r2-task-completion-api-enhancement" lr="21r1.2" app_family="platform" version="21r2">### Task Completion API Enhancement {#21r2-task-completion-api-enhancement}

Retrieve Task Complete API

<Endpoint path="/api/{version}/objects/objectworkflows/tasks/{task_id}/actions/complete" method="GET"></Endpoint>now returns tasks with eSignature.

Completion of tasks with eSignature continues to remain blocked through APIs.

Learn more in the [v21.2 API Reference](/vault-api/api-reference/21.2/object-lifecycle-workflows/workflow-tasks/retrieve-workflow-task-action-details).

</ReleaseNote>
<ReleaseNote id="21r2-prevent-reclassify-for-checkedout-documents" lr="21r1.3" app_family="platform" version="21r2">### Prevent Reclassify for Checked-out Documents {#21r2-prevent-reclassify-for-checkedout-documents}

For all versions of the API, the Reclassify Document endpoint no longer allows reclassification for documents that are currently checked out.

<Endpoint path="/api/{version}/objects/documents/{doc_id}" method="PUT"></Endpoint></ReleaseNote>
<ReleaseNote id="21r2-include-inactive-classification-on-single-document-version" lr="21r1.3" app_family="platform" version="21r2">### Include Inactive Classification on Single Document Version {#21r2-include-inactive-classification-on-single-document-version}

When retrieving single document versions, previous versions of the API return `null` for `classification__v` when the classification is inactive. In API v21.2+, inactive classifications return the classification name.

</ReleaseNote>
<ReleaseNote id="21r2-facetable-attribute" lr="21r1.3" app_family="platform" version="21r2">### Facetable Attribute {#21r2-facetable-attribute}

Metadata describe queries on documents and objects will now return a `facetable` attribute with each field to indicate which fields will return facets when searching document or object tabs in the Vault UI.

</ReleaseNote>
<ReleaseNote id="21r2-remove-duplicate-previous-page-and-next-page-link-in-api-results" lr="21r1.4" app_family="platform" version="21r2">### Remove Duplicate Previous Page and Next Page Link in API results {#21r2-remove-duplicate-previous-page-and-next-page-link-in-api-results}

In API v21.2+, the `/audittrail` endpoints contain only one `previous_page` and `next_page` link.

In previous API versions, these endpoints contain both `previousPage` and `previous_page` as well as `nextPage` and `next_page` links.

</ReleaseNote>
<ReleaseNote id="21r2-audit-api-returns-nulls" lr="21r1.2" app_family="platform" version="21r2">### Audit API Returns Nulls {#21r2-audit-api-returns-nulls}

Audit API JSON responses now include `null` instead of empty strings when a field is blank. This change only affects v21.2+.

Learn more in the [v21.2 API Reference](/vault-api/api-reference/21.2/logs/audit).

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

</ReleaseNote>
<ReleaseNote id="21r2-veeva-safety-inbox-and-imported-case-create-api-from-e2b" lr="21r1.4" app_family="platform" version="21r2">### Veeva Safety: Inbox and Imported Case Create API from E2B {#21r2-veeva-safety-inbox-and-imported-case-create-api-from-e2b}

The Veeva Safety API can now receive E2B files and import to either Imported Cases or Inbox Items. New endpoints have also been introduced for retrieving import status and ACKs.

Learn more in the [v21.2 API Reference](/vault-api/api-reference/21.2/vault-query-language-vql).

</ReleaseNote>

## VQL {#vql}

<ReleaseNote id="21r2-vql-for-document-workflows" lr="21r1.3" app_family="platform" version="21r2">### VQL for Document Workflows {#21r2-vql-for-document-workflows}

This feature allows VQL developers to query Document Workflows (formerly multi-document workflow), workflow tasks, and supports relationships to user data. To access this data, we’ve introduced new query targets for actively running workflows and completed (or cancelled) workflows. Query results can be sorted, filtered, and paginated.

Learn more about [querying document workflows in the VQL documentation](/vql/query-targets/workflows).

</ReleaseNote>
<ReleaseNote id="21r2-number-precision-for-document-field-queries" lr="21r1.2" app_family="platform" version="21r2">### Number Precision for Document Field Queries {#21r2-number-precision-for-document-field-queries}

This feature enhances the decimal precision of field values for *Number* fields. As of VQL v21.2+, document read precision is based on the number field’s configured *Decimal places*.

For example, if you save a document number field with a value of `3.0` and the *Decimal places* for that field is configured as `2`, you will see a field value of `3.00` in VQL query results.

Learn more about [querying number fields with VQL](/vql/references/system-limits-performance/queryable-field-types#Number_Fields_Decimals).

</ReleaseNote>
<ReleaseNote id="21r2-related-object-section-criteria-vql-filters" lr="21r1.2" app_family="platform" version="21r2">### Related Object Section Criteria VQL Filters {#21r2-related-object-section-criteria-vql-filters}

To make filtering consistent across Vault Objects, we are enhancing the related object section filters to use Criteria VQL. Any existing filters will remain unchanged and continue to function as before. Vault will automatically convert legacy filters to Criteria VQL upon edit of the related object section.

Previously, there was an Apply on Create feature that allows an Admin to specify at the individual criteria level indicating if the criteria will be used as default for creating new records. In this release, the Apply on Create feature has been changed to apply to all criteria instead of applying at the individual level.

</ReleaseNote>

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

<ReleaseNote id="21r2-action-icons" lr="21r1.4" app_family="platform" version="21r2">### Action Icons {#21r2-action-icons}

You can now specify one of 10 icons to display in the **Actions** menu for custom record and document actions using the `icon` element of a `RecordActionInfo` or `DocumentActionInfo`  annotation. When a custom action is used frequently by a user, it is displayed in the most frequently used actions section of the Action Bar with the specified icon.

Learn more about [Action Icons](/vault-sdk/entry-points/actions/action-icons).

</ReleaseNote>
<ReleaseNote id="user-defined-model-and-property" lr="21r1.4" app_family="platform" version="21r2">### JSON Binding Annotations: User-Defined Model and Property {#user-defined-model-and-property}

This features introduces a new Vault Java SDK code type, user-defined model, which
supports annotating getters and setters on a Java interface as a user-defined property. Using `JsonService`, developers can serialize a model to JSON and deserialize JSON to a model. Additionally, user-defined models can be used with `HttpService` to send and retrieve data using REST APIs.

Learn more about [user-defined models](/vault-sdk/shared-code/udm).

</ReleaseNote>
<ReleaseNote id="21r2-object-metadata-service-field-type-support" lr="21r1.2" app_family="platform" version="21r2">### Object Metadata Service Field Type Support {#21r2-object-metadata-service-field-type-support}

Starting in 21R1.2, object field types and value types are now available for retrieval as part of the `ObjectMetadataService`. This functionality is extremely useful for use cases where the custom Java SDK code needs to have conditional logic based on the type or value type of a field.

</ReleaseNote>
<ReleaseNote id="21r2-support-patch-on-httprequest" lr="21r1.2" app_family="platform" version="21r2">### Support PATCH on HttpRequest {#21r2-support-patch-on-httprequest}

`HttpRequest` now supports the <span class="label label-warning">PATCH</span> verb when making REST API calls with `HttpService`.

</ReleaseNote>
<ReleaseNote id="21r2-audit-enhancements-on-behalf-of-user" lr="21r1.4" app_family="platform" version="21r2">### Audit Enhancements: On Behalf of User {#21r2-audit-enhancements-on-behalf-of-user}

System and Application events that make data changes will be logged as `System on behalf of {username}`, which provides additional visibility into which user’s actions caused data to be created, updated, or deleted. Previously, these audit entries were logged simply as *System*. Existing audit entries will not be altered and only new audit entries will reflect this additional information.

</ReleaseNote>
<ReleaseNote id="21r2-objectfieldtype-implements-fieldtype-interface" lr="21r1.4" app_family="platform" version="21r2">### ObjectFieldType Implements FieldType Interface {#21r2-objectfieldtype-implements-fieldtype-interface}

`ObjectFieldType` now implements the common `FieldType` interface.

</ReleaseNote>