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

# Vault Developer Release Notes

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

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

We are pleased to bring you the following additions and enhancements to Developer Portal features in 20R2. REST API features added in 20R2 only affect API v20.2, unless otherwise noted. For issues fixed in this release, view the "Developer Features" category of the [fixed issues list in Vault Help](https://platform.veevavault.help/en/lr/63032).

### Service Announcement {#Service_Announcement}

<ReleaseNote id="20r2-veeva-vault-tls-cipher-suite-changes" app_family="platform" version="20r2">### Veeva Vault TLS Cipher Suite Changes {#20r2-veeva-vault-tls-cipher-suite-changes}

Beginning with the 20R3 release, we will be modifying the set of TLS cipher suites supported by Vault servers, removing weak ciphers and changing the priority order to utilize stronger ciphers. These changes may affect some custom integrations, but not users accessing Vault with a supported browser.

<aside class="notice">Changes begin rolling out for Limited Release users with version 20R2.2.</aside>All customers with affected integrations will be contacted directly by Veeva Services prior to any changes so that they can test their integrations. Testing can be performed on a limited release sandbox beginning with the 20R2.2 release (August 21, 2020).

Learn more about [Veeva Vault cipher suite changes](/docs/tls/cipher).

</ReleaseNote>

### REST API v20.2 {#20r2-rest-api-v202}

REST API features added in 20R1 only affect API v20.2, unless otherwise noted.

<ReleaseNote id="20r2-list-nodes-api" lr="20r1.4" app_family="platform" version="20r2">### List Nodes API {#20r2-list-nodes-api}

This new API will return a list of Hierarchy Node IDs based on an input list of up to 1,000 EDL record ID’s. This is useful for looking up unknown node IDs for an EDL hierarchy that needs to be reordered via the API.
Learn more in the [API Reference](/vault-api/api-reference/20.2/expected-document-lists/retrieve-specific-root-nodes).

</ReleaseNote>
<ReleaseNote id="20r2-api-bulk-active-workflow-actions-cancel-workflow" lr="20r1.4" app_family="platform" version="20r2">### API Bulk Active Workflow Actions - Cancel Workflow {#20r2-api-bulk-active-workflow-actions-cancel-workflow}

This feature adds three new endpoints to the REST API:

Retrieve all available workflow actions that can be initiated on a workflow in a Vault. Currently, only the `cancelworkflows` action is available.

<Endpoint path="/api/{version}/object/workflows/actions" method="GET"></Endpoint>Retrieve the details for a specific workflow action, including the input prompts required to initiate the action.

<Endpoint path="/api/{version}/object/workflows/actions/{action}" method="GET"></Endpoint>With the following endpoint, users with cancel workflow permission can cancel active instances of workflows by submitting a comma separated list of workflow IDs. After submitting the list of workflows, Vault returns a Job ID which can be used to check on the status of the asynchronous job process. The user also receives an email message that summarizes any errors that were encountered.

<Endpoint path="/api/{version}/object/workflows/actions/{action}" method="POST"></Endpoint>View these endpoints in the [v20.2 API Reference](/vault-api/api-reference/20.2/bulk-active-workflow-actions).

</ReleaseNote>
<ReleaseNote id="20r2-object-md-workflow-variables" lr="20r1.3" app_family="platform" version="20r2">### Object & MD Workflow Variables {#20r2-object-md-workflow-variables}

In this release, API users can initiate object workflows and multi-document workflows configured with the new prompt type `variable`. These new prompts can include “String Variable”, “Boolean Variable”, and “Picklist Variable”.

</ReleaseNote>
<ReleaseNote id="20r2-inbound-component-dependency-validation" lr="20r1.3" app_family="platform" version="20r2">### Inbound Component Dependency Validation {#20r2-inbound-component-dependency-validation}

This feature enhances the [Deploy Package](/vault-api/api-reference/20.2/configuration-migration/deploy-package) endpoint to run a dependency validation prior to starting a deployment job. If there are any steps that have a **Blocked** status, Vault will not start the deployment job.

</ReleaseNote>
<ReleaseNote id="20r2-document-migration-mode-for-vault-loader" lr="20r1.3" app_family="platform" version="20r2">### Document Migration Mode for Vault Loader {#20r2-document-migration-mode-for-vault-loader}

The **Load Data Objects** endpoint now accepts the `documentmigrationmode` parameter when creating documents where the `object_type` is` document_versions__v`, `document_renditions__v`, or `document_versions_roles__v`. This creates documents in a specific state or state type and allows you to set the name, document number, and version number without placing the entire Vault in Migration Mode. In order to use this feature, you must have the new *Document Migration* permission.

</ReleaseNote>
<ReleaseNote id="20r2-document-migration-mode-api-header" lr="20r1.2" app_family="platform" version="20r2">### Document Migration Mode API Header {#20r2-document-migration-mode-api-header}

Some bulk API calls, including bulk document version creation, previously required enabling Migration Mode for the entire Vault which disrupts auto-matching processes such as EDL and Legal Hold. These calls can now include a new document migration mode header instead. In order for the header to be accepted, the API user must have the new *Document Migration* permission in their security profile’s permission sets.

Learn more about the [Document Migration Mode API Header](/vault-api/api-reference/20.2/vault-query-language-vql).

</ReleaseNote>
<ReleaseNote id="20r2-vpk-deployment-order-dependency-and-validation" lr="20r1.2" app_family="platform" version="20r2">### VPK Deployment Order Dependency and Validation {#20r2-vpk-deployment-order-dependency-and-validation}

This feature introduces enhancement to the [Export Package](/vault-api/api-reference/20.2/configuration-migration/export-package) endpoint to leverage the component relationships of supported components to determine the best deployment order for all components within an outbound package. Additionally, the [Import Package](/vault-api/api-reference/20.2/configuration-migration/import-package) endpoint now includes a link to retrieve the current status of the import job and sends a separate email containing a link to the validation log to the authenticated user. This endpoint also starts an asynchronous process and includes enhancements introduced in 20R1 to validate migration packages prior to importing and deploying.

This feature also adds one new endpoint. The [Validate Inbound Package](/vault-api/api-reference/20.2/configuration-migration/validate-inbound-package) endpoint allows an Admin or configuration specialist to re-validate an inbound package after importing. This validation endpoint includes information about the dependent components, whether they are required, and whether they exist in the inbound package or the target Vault.

</ReleaseNote>
<ReleaseNote id="20r2-submission-join-filters" lr="20r1.2" app_family="platform" version="20r2">### Submission Join Filters {#20r2-submission-join-filters}

Submission Join Filters leverages existing submission relationships as filters in the Submissions Archive Viewer and replaces the filters provided through metadata mapping. In Vaults with Submission Join Filters enabled, the [Submission Metadata Mapping API](/vault-api/api-reference/20.2/vault-query-language-vql) will return a `METHOD_NOT_SUPPORTED` response.

</ReleaseNote>
<ReleaseNote id="20r2-safetyai-intake-api" lr="20r1.3" app_family="platform" version="20r2">### Safety.AI Intake API {#20r2-safetyai-intake-api}

Veeva Safety.AI integrates with the Vault API to introduce a publicly accessible endpoint for high-volume case intake.
The Intake API can be used to import new cases from a JSON file. The source JSON file can contain both structured and unstructured data. After a successful operation, the system extracts the data using AI and natural language processing to create an Inbox item for verification.

</ReleaseNote>

### VQL {#20r2-vql}

VQL features added in 20R1 only affect v20.2, unless otherwise noted.

<ReleaseNote id="20r2-vql-support-for-strict-matching" lr="20r1.3" app_family="platform" version="20r2">### VQL Support for Strict Matching {#20r2-vql-support-for-strict-matching}

This feature enables support for Strict Matching in VQL. This feature was introduced in Vault Search in 20R1.2. Learn more about [Strict Matching in Vault Help](https://platform.veevavault.help/en/lr/61691#about_strict_matching).

When you enable **Strict Matching**, VQL applies the same logic as Vault Search to the `FIND` operator in regards to minimum matching:

* Searches with one or two terms require all terms to match

* Searches with three or four terms require all but one term to match

* Searches with five or more terms require all but two terms to match

Vault will apply the negated Minimum Match to the whole search string in cases where the `NOT` operator is specified on the outside of the search string, for example, `FIND (NOT 'term1 term2')`.
Strict Matching will also apply a 100% Minimum Match to queries which use the `FIND` command and only `AND` operators. For example, when all of the terms in the search String are combined using the `AND` operator inside the VQL `FIND` command, 100% Minimum Match is applied. This is similar to the **All of these words** feature in the Vault UI Advanced Search.

As part of this feature, VQL also now takes advantage of the new rule-based stemmer in English, French, and German to reduce the inflected form of words down to their root form in both the index and the query. This makes it easier to find things since you don’t have to get the tense or plurality of a word right to get a match.

This feature also enhances the ID pattern matching. When a single search term has an alphanumeric, or ID pattern, VQL applies special handling to make sure you always get an exact match. The ID pattern can be either of the following:

* A mix of letters and numbers (ABC123, A1B2C3)

* A string with punctuation (VV-QUAL-0001, ABC.DEF, 123_456)

These types of searches are tokenized, and all tokens are required to match in the correct order. This allows users to search for the middle or end of an ID and get a correct match.

</ReleaseNote>
<ReleaseNote id="20r2-vql-tokenizer-enhancements" lr="20r1.3" app_family="platform" version="20r2">### VQL Tokenizer Enhancements {#20r2-vql-tokenizer-enhancements}

This feature enhances the tokenizer used for the VQL `FIND` command. With this enhancement the `tokenize` query parameter is being deprecated and will no longer have any effect on term tokenization. Synonym matching now works without having to set the `tokenize` parameter.

</ReleaseNote>
<ReleaseNote id="20r2-vql-rank-field-enhancements" lr="20r1.2" app_family="platform" version="20r2">### VQL Rank Field Enhancements {#20r2-vql-rank-field-enhancements}

As of this release, the `rank` field can no longer be included in the `SELECT` clause for Query API versions v20.2 and higher. Sorting query results by relevance by using `ORDER BY rank` is still available for all document queries using `FIND()` syntax.

</ReleaseNote>
<ReleaseNote id="20r2-vql-result-ordering-enhancements" lr="20r1.2" app_family="platform" version="20r2">### VQL Result Ordering Enhancements {#20r2-vql-result-ordering-enhancements}

In this release, we’ve made several enhancements to keep the ordering of VQL results consistent and predictable. Previously for some `ALLVERSIONS` document queries without `ORDER BY`, multiple versions of the same document may have appeared in a random order. Starting in 20R1.2 for VQL v9+, these queries will now be sorted by descending document version ID. Additionally, using `ORDER BY` with a non-unique field may have returned results in an unpredictable order. For example, a user could call the same query on two different Vault versions and see the same results displayed in a different order. Starting in 20R1.2 for all versions of VQL, all queries with `ORDER BY` will return in a predictable order.

Additionally, for all versions of VQL, the default sort order for VQL object queries now matches that of UI searches. For VQL `FIND` queries on documents, use `ORDER BY rank` to achieve the same sort order as UI search. To ensure a particular sort order, you are encouraged to always specify a desired sort order by using an `ORDER BY` clause.

</ReleaseNote>

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

<ReleaseNote id="20r2-custom-job-processors-with-the-vault-java-sdk" lr="20r1.3" app_family="platform" version="20r2">### Custom Job Processors with the Vault Java SDK {#20r2-custom-job-processors-with-the-vault-java-sdk}

Customers can now create custom job processors using the Vault Java SDK. These `Jobs` are split up into multiple `JobTasks` which can operate on up to 500 items at a time, allowing jobs to run on large data sets without exceeding the standard SDK limits.

After associating a `Jobmetadata` MDL component with a job processor, the job can be invoked on-demand via SDK triggers or actions, or it can be run on a schedule by using a job definition. Once a job is initiated, it will run until all job tasks are complete and provide a log file with information about the job.

</ReleaseNote>
<ReleaseNote id="20r2-spark-integration-rules-ui" lr="20r1.3" app_family="platform" version="20r2">### Spark Integration Rules UI {#20r2-spark-integration-rules-ui}

Administrators can now configure Integration Rules through the Vault UI. The UI provides real-time validations of configurations through prompting for both the local and remote Vault options. While MDL is still fully supported for Integration Rule creation and modification, we suggest using the Vault UI.
Learn more about the [new Integration Rules UI in Vault Help](https://platform.veevavault.help/en/lr/62154).

</ReleaseNote>
<ReleaseNote id="20r2-object-multidocument-workflow-invoke-record-action-via-a-system-action-step" lr="20r1.2" app_family="platform" version="20r2">### Object & Multi-document Workflow: Invoke Record Action via a System Action Step {#20r2-object-multidocument-workflow-invoke-record-action-via-a-system-action-step}

This feature enables Vault Java SDK developers to add a Record Action to a System Action step for an Object Workflow or a Multi-document Workflow. After an Admin configures the system step invoking the record action, Vault executes the custom logic as part of the workflow.

Learn more in the [Javadocs](https://repo.veevavault.com/javadoc/vault-sdk-api/20.1.2/docs/api/com/veeva/vault/sdk/api/action/package-summary.html).

</ReleaseNote>
<ReleaseNote id="20r2-reestablish-vault-to-vault-connection" lr="20r1.2" app_family="platform" version="20r2">### Re-establish Vault to Vault Connection {#20r2-reestablish-vault-to-vault-connection}

Prior to v20.2, connections could not be broken and re-established. When developing, shutting down and spinning up new Vaults is common (through refresh, cloning, or simply creating a new sandbox Vault). Now as you refresh, clone, or create a new Vault it can reconnected to an existing connection on a remote Vault so that you can continue developing.
Using the new Re-establish Vault to Vault Connection feature lets you connect an existing connection to a new Vault, either source Vault or target Vault.

</ReleaseNote>
<ReleaseNote id="20r2-signed-data-to-include-http-url-parameters" lr="20r1.2" app_family="platform" version="20r2">### Signed Data to Include Http URL Parameters {#20r2-signed-data-to-include-http-url-parameters}

In this release, we’ve added a new signature to the Spark message header which signs the URL query parameters: `X-VaultAPISignatureV2`. To adopt this new signature, you must also append the full URL to your String-to-verify. Learn more in the [Message Format](/vault-sdk/sdk-integrations/spark-messaging/message-format) documentation.

The original signature, `X-VaultAPISignature` is still available allowing all existing signatures to continue to work, but we recommend adopting the new signature.

</ReleaseNote>

### MDL {#20r2-mdl}

<ReleaseNote id="20r2-mdl-for-hourly-jobs" lr="20r1.2" app_family="platform" version="20r2">### MDL for Hourly Jobs {#20r2-mdl-for-hourly-jobs}

The Job component offers a new hourly option so that jobs can be scheduled to run more than once per day. Hourly jobs are scheduled with the new `hourly_interval` attribute and allow scheduling intervals as frequently as every hour, or as infrequently as every 12 hours with several options in between for additional scheduling flexibility.

Learn more about [MDL for Hourly Jobs](/mdl/component-reference/component-types/job).

</ReleaseNote>