**Source URL:** https://general.veevavault.dev/rn/19r1.md

# Vault Developer Release Notes

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

## Developer Features in 19R1 {#developer-features-in-19r1}

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](https://platform.veevavault.help/en/lr/53575).

### Metadata Definition Language (MDL) {#19r1-metadata-definition-language-mdl}

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](/mdl/documentation/overview).

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

<ReleaseNote id="19r1-spark-messaging" label="March 1, 2019" app_family="platform" version="19r1">### Spark Messaging {#19r1-spark-messaging}

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](/vault-sdk/sdk-integrations/).

</ReleaseNote>
<ReleaseNote id="19r1-http-callout" label="March 1, 2019" app_family="platform" version="19r1">### HTTP Callout {#19r1-http-callout}

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](/vault-sdk/sdk-integrations/http-callout/).

</ReleaseNote>
<ReleaseNote id="19r1-triggers-on-direct-role-assignment-object" label="February 8, 2019" app_family="platform" version="19r1">### Triggers on Direct Role Assignment (Object) {#19r1-triggers-on-direct-role-assignment-object}

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](/vault-sdk/entry-points/triggers/role-triggers/).

</ReleaseNote>
<ReleaseNote id="19r1-event-actions-on-documents" label="December 14, 2018" app_family="platform" version="19r1">### Event Actions on Documents {#19r1-event-actions-on-documents}

<aside class="notice">Event Action support for Vault Java SDK actions is not automatically available. If your organization would like to use this functionality, please contact Veeva Support.

</aside>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`.

</ReleaseNote>

### REST API v19.1 {#19r1-rest-api-v191}

<ReleaseNote id="19r1-automated-image-renditions" label="February 8, 2019" app_family="platform" version="19r1">### Automated Image Renditions {#19r1-automated-image-renditions}

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](/vault-api/api-reference/19.1/documents/document-renditions) to retrieve, download, or delete the new rendition type.

</ReleaseNote>
<ReleaseNote id="19r1-rendition-profiles" label="February 8, 2019" app_family="platform" version="19r1">### Rendition Profiles {#19r1-rendition-profiles}

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](/vault-api/api-reference/19.1/vault-objects) to retrieve Rendition Profile (`rendition_profile_sys`) record details.

</ReleaseNote>
<ReleaseNote id="19r1-oauth-20-openid-connect" app_family="platform" version="19r1">### OAuth 2.0 / OpenID Connect {#19r1-oauth-20-openid-connect}

</ReleaseNote>
<ReleaseNote id="19r1-support-pingfederate-remote-keys-for-access_token-validation" label="February 8, 2019" app_family="platform" version="19r1">### Support PingFederate Remote Keys for access_token Validation {#19r1-support-pingfederate-remote-keys-for-access_token-validation}

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_token`s. This will enable Vault to validate the signatures of JWT `access_token`s locally instead of using a remote Authorization Server (AS) callout, thus improving the stability and performance when integrating with PingFederate AS.

</ReleaseNote>
<ReleaseNote id="19r1-clientid-mapping" label="December 14, 2018" app_family="platform" version="19r1">### ClientID Mapping {#19r1-clientid-mapping}

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](/vault-api/api-reference/19.1/authentication/authentication-type-discovery) can now accept the native application client ID and will include the client ID of the remote Authorization Server if the mapping is configured.

</ReleaseNote>
<ReleaseNote id="19r1-client-id-supports-uppercase-characters" label="December 14, 2018" app_family="platform" version="19r1">### Client ID Supports Uppercase Characters {#19r1-client-id-supports-uppercase-characters}

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](/docs/#Client_ID).

</ReleaseNote>
<ReleaseNote id="19r1-enhanced-vault-formulas" label="February 8, 2019" app_family="platform" version="19r1">### Enhanced Vault Formulas {#19r1-enhanced-vault-formulas}

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.

</ReleaseNote>
<ReleaseNote id="19r1-create-record-in-noninitial-state" label="December 14, 2018" app_family="platform" version="19r1">### Create Record in Non-Initial State {#19r1-create-record-in-noninitial-state}

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.

</ReleaseNote>
<ReleaseNote id="19r1-activate-and-inactivate-picklist-values" label="December 14, 2018" app_family="platform" version="19r1">### Activate and Inactivate Picklist Values {#19r1-activate-and-inactivate-picklist-values}

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:

<Endpoint path="/api/{version}/objects/picklists/{picklist_name}/{picklist_value_name}" method="PUT"></Endpoint>They then pass in `status` as the body parameter, and either `Active` or `Inactive` as the status value.

</ReleaseNote>

### VQL Documentation Improvements {#19r1-vql-documentation-improvements}

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.

<ReleaseNote id="19r1-activate-and-inactivate-picklist-values" label="December 14, 2018" app_family="platform" version="19r1">### Documentation Location {#documentation-location}

Previously, the VQL documentation was located under the References heading. We’ve moved this to its own section under the Documentation heading.

</ReleaseNote>
<ReleaseNote id="19r1-activate-and-inactivate-picklist-values" label="December 14, 2018" app_family="platform" version="19r1">#### Query Endpoint {#query-endpoint}

We’ve added a section with details about the `/api/{version}/query` endpoint to the v19.1 REST API under the References tab.

</ReleaseNote>
<ReleaseNote id="19r1-activate-and-inactivate-picklist-values" label="December 14, 2018" app_family="platform" version="19r1">#### Content & Structure Changes {#content--structure-changes}

We’ve made the following updates to VQL’s content and structure:

* Added a Getting Started section that provides a step-by-step walkthrough for searching documents

* Updated organization to include individual headings for each VQL clause

* Revised the structure of our example queries to improve readability

* Reorganized content to ensure new feature documentation is easier to locate and appear logically within the documentation

</ReleaseNote>