We are pleased to bring you the following additions and enhancements to Developer Portal features in 19R1. REST API features added in 19R1 only affect API v19.1, unless otherwise noted. You can learn more about the 19R1 Release in Vault Help.
Release Date: April 19, 2019
Metadata Definition Language (MDL) is a metadata management framework and an associated language to build and manage Vault configuration components. With MDL, you can create and execute scripts on your Vault to automate complex or repetitive configuration changes. For example, changing the configuration of 100 document types requires at least 100 clicks in the Vault Admin UI, which was laborious and error-prone. With MDL, this task can be scripted once and subsequently completed in seconds.
Learn more about MDL.
Release Date: March 1, 2019
Vault developers can use the Vault Java SDK to send message notifications as events occur in a Vault. Spark messages are lightweight, signed messages sent via HTTPS. Outbound messages are processed by a queuing system to provide reliable delivery. Inbound messages received from another Vault is processed by custom Java SDK code. This feature enables near real-time integration between Vaults and with external systems.
Learn more about Spark Messaging.
Release Date: March 1, 2019
Vault developers can use HttpService in the Vault Java SDK to send requests to an endpoint, including the Vault REST API or external application APIs. Requests sent to another Vault are made through a trusted connection to allow data access control. Requests sent to external applications support basic username and password authentication. Builder and reader utilities for JSON and CSV data is provided to work with the request and response body content. This feature enables real-time integration with another Vault or external applications.
Learn more about HTTP Callout.
Release Date: February 8, 2019
This feature allows customers to execute custom Java SDK code before or after a manual role assignment or un-assignment Event on an object record. Customers can use record role triggers on BEFORE events to perform specific validations, and AFTER event triggers for cascading access or sending notifications after role assignment. Learn more about role triggers.
Release Date: December 14, 2018
Event actions are configurable actions that take place automatically when a user creates a new document, creates a new draft of an existing document, or creates a copy of an existing document. In the current release, you can only configure event actions with a custom action coded through Vault Java SDK.
To make an action available for configuration as a document event action, specify the usage as LIFECYCLE_ENTRY_ACTION in @DocumentActionInfo.
Release Date: February 8, 2019
Automated Image Renditions allow Admins in PromoMats and MedComms Vaults to define specific renditions types for image files and apply them to any necessary document types, subtypes, or classifications through the UI. API users can use the existing Document Rendition endpoints to retrieve, download, or delete the new rendition type.
Release Date: February 8, 2019
Rendition Profiles provide the ability to specify a set of rendition settings for a document. When uploading a document, Vault generates the PDF rendition based on the Rendition Profile specified for the document instead of the Vault wide rendition settings. API users can use the existing Vault Object endpoints to retrieve Rendition Profile (rendition_profile_sys) record details.
Release Date: February 8, 2019
With this feature, Vault OAuth 2.0 / OpenID Connect profiles will now contain a PingFederate Authorization Server specific configuration option called “Access Token JWKS Endpoint”. Use this option to specify an additional JWKS endpoint containing the validation keys used to validate signatures for JWT access_tokens. This will enable Vault to validate the signatures of JWT access_tokens locally instead of using a remote Authorization Server (AS) callout, thus improving the stability and performance when integrating with PingFederate AS.
Release Date: December 14, 2018
With this release OAuth 2.0 / OpenID Connect Profiles support managing mapping between client IDs defined by Authorization Servers and client IDs defined in client applications. This allows integrating with Authorization Servers where client IDs must be uniquely generated per each app and cannot be configured with the static client IDs built into native applications such as Vault File Manager or Veeva Snap. To take advantage of this feature, the Discovery API can now accept the native application client ID and will include the client ID of the remote Authorization Server if the mapping is configured.
Release Date: December 14, 2018
For additional tracking purposes, every Vault REST API call accepts an optional client_id to represent an external integration client. As of this release, client_id supports uppercase characters in all versions of the API. Learn more about Client ID in the REST API Documentation.
Release Date: February 8, 2019
This feature improves Vault Formula capabilities, usability, and performance. By introducing new operators, new functions, and the @User system variable, customers can streamline their formulas and perform new calculations. Customers may also return a null value in formulas and are no longer required to add an object prefix to each object reference.
Starting in API v19.1, metadata APIs for objects and workflows where object fields are referenced in formulas will have the object prefix of the reference removed, leaving only the field and relationship.
All existing expressions will continue to function as they do today.
Release Date: December 14, 2018
Vault Owners can now migrate or create object records in non-initial lifecycle states using Vault’s Object Record Creation API. Vault Owners can specify X-VaultAPI-MigrationMode=true in API header and provide a valid lifecycle state (state__v) field value in the API body to create record in any lifecycle state.
Release Date: December 14, 2018
You can now update the status (Active/Inactive) of a picklist value via the API. Prior to this release, deleting a picklist value just inactivated the value and hid it from admin. In order to re-activate an inactivated value, an API user makes the following call:
PUT /api/{version}/objects/picklists/{picklist_name}/{picklist_value_name}
They then pass in status as the body parameter, and either Active or Inactive as the status value.
Release Date: April 19, 2019
With this release, we’ve made significant enhancements to our VQL documentation to improve content, site navigation, and overall usability. The revised documentation now uses a more logical and structured organization, which means some content may not be in the same place. However, any existing bookmarks and links should redirect you to the right place. See below for more detailed information about VQL’s revised documentation.
Previously, the VQL documentation was located under the References heading. We’ve moved this to its own section under the Documentation heading.
We’ve added a section with details about the /api/{version}/query endpoint to the v19.1 REST API under the References tab.
We’ve made the following updates to VQL’s content and structure: