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.
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.
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.
REST API features added in 20R1 only affect API v20.2, unless otherwise noted.
Release Date: 20R1.4, June 26, 2020
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.
Release Date: 20R1.4, June 26, 2020
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.
GET /api/{version}/object/workflows/actions
Retrieve the details for a specific workflow action, including the input prompts required to initiate the action.
GET /api/{version}/object/workflows/actions/{action}
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.
POST /api/{version}/object/workflows/actions/{action}
View these endpoints in the v20.2 API Reference.
Release Date: 20R1.3, June 5, 2020
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”.
Release Date: 20R1.3, June 5, 2020
This feature enhances the 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.
Release Date: 20R1.3, June 5, 2020
The Load Data Objects endpoint now accepts the documentmigrationmode parameter when creating documents where the object_type isdocument_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.
Release Date: 20R1.2, May 1, 2020
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.
Release Date: 20R1.2, May 1, 2020
This feature introduces enhancement to the 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 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 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.
Release Date: 20R1.2, May 1, 2020
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 will return a METHOD_NOT_SUPPORTED response.
Release Date: 20R1.3, June 5, 2020
Vault 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.
VQL features added in 20R1 only affect v20.2, unless otherwise noted.
Release Date: 20R1.3, June 5, 2020
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.
When you enable Strict Matching, VQL applies the same logic as Vault Search to the FIND operator in regards to minimum matching:
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:
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.
Release Date: 20R1.3, June 5, 2020
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.
Release Date: 20R1.2, May 1, 2020
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.
Release Date: 20R1.2, May 1, 2020
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.
Release Date: 20R1.3, June 5, 2020
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.
Release Date: 20R1.3, June 5, 2020
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.
Release Date: 20R1.2, May 1, 2020
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.
Release Date: 20R1.2, May 1, 2020
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.
Release Date: 20R1.2, May 1, 2020
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 documentation.
The original signature, X-VaultAPISignature is still available allowing all existing signatures to continue to work, but we recommend adopting the new signature.
Release Date: 20R1.2, May 1, 2020
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.