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

# Vault Developer Release Notes

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

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

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

<ReleaseNote id="19r2-person-organization-migration-clinical" label="June 21, 2019" app_family="platform" version="19r2">### Person & Organization Migration (Clinical) {#19r2-person-organization-migration-clinical}

This feature introduces a series of changes to your Veeva Clinical application objects. These changes serve to streamline the process of creating Person, Study Person, and Study Organization object records. Additionally, these updates serve as the foundation for future Veeva Clinical functionality and automation.

</ReleaseNote>

### Person__v to Person__sys Migration {#person__v-to-person__sys-migration}

This feature migrates `person__v` fields, relationships (inbound and outbound), and records to the `person__sys` object. Users must update any APIs referencing `person__v` to reference `person__sys`. Additionally, Vault migrates field names from `person__v` to `person__sys` allowing specific field names referenced through the API to remain the same.

<ReleaseNote id="19r2-study-person-and-study-team-assignment-consolidation" app_family="platform" version="19r2">#### Study Person and Study Team Assignment Consolidation {#19r2-study-person-and-study-team-assignment-consolidation}

This feature also migrates *Study Team Assignment* (`team_assignment__v`) relationships and records to the *Study Person* (`study_person__clin`) object. Users must update any APIs referencing *Study Team Assignment* or *Study Team Assignment* fields to reference *Study Person*.

Users may need to update any APIs referencing *Study Person* to reflect the following changes:

* The required *Person* field on *Study Person* will now reference `person__sys`.

* A required *Study Team Role* (`team_role__v`) reference field on *Study Person*.

* A required, Yes/No *Grant Access to Related Records* field on *Study Person*.

</ReleaseNote>
<ReleaseNote id="19r2-study-organization" app_family="platform" version="19r2">#### Study Organization {#19r2-study-organization}

If you enable this new feature, the *Organization Role* picklist field (`organization_role__v`) will be renamed with a new label *Organization Role (deprecated)*. Instead, we encourage you to use the new *Organization Role* object (`organization_role__v`). While API integrations will still work with the deprecated *Organization Role* picklist, we plan to completely remove this field in the future and encourage updating your integrations to use the new object as soon as possible.

</ReleaseNote>
<ReleaseNote id="19r2-vault-java-sdk" app_family="platform" version="19r2">### Vault Java SDK {#19r2-vault-java-sdk}

</ReleaseNote>
<ReleaseNote id="19r2-management-of-signing-certificates-for-saml-spark" label="June 21, 2019" app_family="platform" version="19r2">#### Management of Signing Certificates for SAML & Spark {#19r2-management-of-signing-certificates-for-saml-spark}

Veeva normally rolls the signing certificates for SAML and Spark every two years. This feature will allow Vault Admins to test the new signing certificate during the rollover period. The rollover period is the time between when the new certificate becomes available and the old certificate expires.

</ReleaseNote>
<ReleaseNote id="19r2-record-actions-on-object-lifecycles" label="May 31, 2019" app_family="platform" version="19r2">#### Record Actions on Object Lifecycles {#19r2-record-actions-on-object-lifecycles}

Previously, record actions only supported use as a user action. With this release, record actions now support usage as lifecycle user actions, entry actions, and event actions.

Note that any existing record actions with `usage` set to `UNSPECIFIED` (or where `usage` is omitted) will automatically become available for configuration in these new usages.

Learn more about [Record Actions](/vault-sdk/entry-points/actions/record-actions).

</ReleaseNote>
<ReleaseNote id="19r2-record-workflow-actions" label="May 31, 2019" app_family="platform" version="19r2">#### Record Workflow Actions {#19r2-record-workflow-actions}

In this release, Vault Admins can extend object workflow capabilities with the Workflow SDK. Admins can use a custom action in the workflow Start step to define the participants. Admins can also use a custom action on a workflow Task step to execute custom logic on workflow events such as task creation, completion, reassignment, and cancellation.

Developers can create these custom actions by implementing the new `RecordWorkflowAction` interface with the `@RecordWorkflowActionInfo` annotation. On the annotation, developers can select the step types (either `START` or `TASK`) defining where in Vault the action is available for configuration.

Learn more about [Record Workflow Actions](/vault-sdk/entry-points/actions/record-workflow-actions).

</ReleaseNote>
<ReleaseNote id="19r2-spark-integration-rules" label="May 31, 2019" app_family="platform" version="19r2">#### Spark Integration Rules {#19r2-spark-integration-rules}

Spark Integration Rules allow Java SDK Message Processors developers to use configurable rules for mapping object and document fields for Vault to Vault integrations. Users must first set up Integrationrule components, which are configurable rule sets for field mapping, reference lookup, and field defaulting. Once configured, you can evaluate integration rules within a `MessageProcessor` using new Java SDK services.

**Please contact Veeva Support to set up Integrationrule components.**

Learn more about [Spark Integration Rules](/vault-sdk/sdk-integrations/spark-messaging/integration-rules).

</ReleaseNote>

### REST API v19.2 {#19r2-rest-api-v192}

<ReleaseNote id="19r2-document-role-check-for-document-change-control" label="June 21, 2019" app_family="platform" version="19r2">#### Document Role Check for Document Change Control {#19r2-document-role-check-for-document-change-control}

Given a Document Change Control record ID and an Application Role, this new API endpoint checks if any document added to that record (using the standard *Documents to be Released* and *Documents to be Made Obsolete* relationships) has one or more users in that role.

<Endpoint path="/api/{version}/vobjects/document_change_control__v/{record_id}/actions/documentrolecheck" method="POST"></Endpoint>View this endpoint in the [v19.2 API Reference](/vault-api/api-reference/19.2/vault-query-language-vql).

</ReleaseNote>
<ReleaseNote id="19r2-vault-loader-api" label="May 31, 2019" app_family="platform" version="19r2">#### Vault Loader API {#19r2-vault-loader-api}

In this release, we’ve provided two Vault Loader REST APIs allowing developers to leverage the loader services from an external integration program. Customers can leverage these REST APIs to perform bulk data extract and load for a set of data objects.

Learn more about the [Vault Loader API](/vault-api/api-reference/19.2/vault-loader).

</ReleaseNote>
<ReleaseNote id="19r2-response-headers-for-burst-and-daily-limits" label="May 31, 2019" app_family="platform" version="19r2">#### Response Headers for Burst and Daily Limits {#19r2-response-headers-for-burst-and-daily-limits}

With this feature, each Vault API call that is subject to API Limits will include two additional HTTP headers in the Response:

* `X-VaultAPI-BurstLimit`: The configured maximum number of calls allowed within the burst limit

* `X-VaultAPI-DailyLimit`: The configured maximum number of calls allowed within the daily limit

Learn more about [API rate limits](/docs/#api_rate_limits).

</ReleaseNote>
<ReleaseNote id="19r2-dependent-picklists-for-objects" label="May 31, 2019" app_family="platform" version="19r2">#### Dependent Picklists for Objects {#19r2-dependent-picklists-for-objects}

This feature allows Vault Admins to create picklist dependencies on object picklist fields to only show a subset of the available values controlled by another picklist or Yes/No field on the same object. Vault Admins can set picklist dependencies using the object metadata APIs. Additionally, this feature adds the `controlling_picklist` and `picklist_dependencies` attributes on the `Object` component type to set up picklist dependencies using MDL.

</ReleaseNote>
<ReleaseNote id="19r2-object-field-encryption" label="May 31, 2019" app_family="platform" version="19r2">#### Object Field Encryption {#19r2-object-field-encryption}

All object data in Vault today is stored on encrypted disks. In addition to our normal encryption, this feature allows Vault Admins to mark an object field value as encrypted. This provides an additional layer of security for critical data such as Protected Health Information (PHI).

Veeva will then encrypt the values of such fields and store them in the database as encrypted. The values are decrypted upon a read request, which means API integrations, VQL, and Vault extensions created with the Java SDK can continue to read these field values.

</ReleaseNote>
<ReleaseNote id="19r2-scalable-ftp" label="May 31, 2019" app_family="platform" version="19r2">#### Scalable FTP {#19r2-scalable-ftp}

This release introduces an upgraded Vault FTP infrastructure which makes it more robust, scalable, and future-proof by taking a greater advantage of AWS™. This feature includes the following:

* Improvement for the complete migration lifecycle that generally includes moving and testing document creation across in development, validation and production environment

* Improved visibility when the documents are ready for consumption

* Expedite the time it takes for documents to become usable in Vault after uploading files

<aside class="notice">Beginning June 27, 2019 through the second week of August, we are rolling out changes to the FTP server functionality. Once the changes have been made for your Vault, you will no longer be able to rename or move folders on the FTP server.</aside>Learn more about [Scalable FTP](/docs/#Scalable_FTP).

</ReleaseNote>
<ReleaseNote id="19r2-upload-to-ftp-for-non-system-admins" label="April 26, 2019" app_family="platform" version="19r2">#### Upload to FTP for non System Admins {#19r2-upload-to-ftp-for-non-system-admins}

With this release, all users with FTP staging permission can upload submission dossiers to the FTP server within their *Submissions Archive Import* folder, rather than only within their user folder. This additional import location can be used as the source location when importing submissions through the RIM Submissions Archive Import API.

Learn more about [Importing Submissions](/vault-api/api-reference/19.2/vault-query-language-vql).

</ReleaseNote>
<ReleaseNote id="19r2-asynchronous-md5-checksum-and-mimetype-calculation-for-batch-document-creation" label="May 31, 2019" app_family="platform" version="19r2">#### Asynchronous MD5 Checksum and MIME-Type Calculation for Batch Document Creation {#19r2-asynchronous-md5-checksum-and-mimetype-calculation-for-batch-document-creation}

With this feature, when calling the bulk document creation API on files uploaded via FTP, Vault does not update the MD5 checksum right away and instead sets it to *pending*. When querying MD5 checksum through VQL, via the Documents API, or read in the document/binder exports, Vault returns the value as *pending*. Additionally, the process of calculating the MD5 checksum will become asynchronous.

Further, the process that determines the mime-types of uploaded files will use a "best effort" approach when calling the bulk document creation API. The final calculation and confirmation of the mime-types will become an asynchronous process.

This new asynchronous process increases the performance of bulk creation of documents.

</ReleaseNote>
<ReleaseNote id="19r2-vault-compare-enhancements" label="April 26, 2019" app_family="platform" version="19r2">#### Vault Compare Enhancements {#19r2-vault-compare-enhancements}

In this release, we’ve enhanced the Vault Compare endpoint to support the following settings and configurations for comparison:

* Document & Binder Templates

* Default Rule & Override Rules

* Vault Settings

To include these settings, set the following optional body parameters to `true`:

* `include_doc_binder_templates`

* `include_vault_settings`

Additionally, the `component_types` parameter now accepts the `none` value to exclude component types from the comparison report.

Learn more about [Vault Compare](/vault-api/api-reference/19.2/configuration-migration/vault-compare).

</ReleaseNote>

### Vault Query Language {#19r2-vault-query-language}

<ReleaseNote id="19r2-vql-deletedstate-document-function" label="May 31, 2019" app_family="platform" version="19r2">#### VQL DELETEDSTATE() Document Function {#19r2-vql-deletedstate-document-function}

In this release, we’ve added a `DELETEDSTATE()` document function to VQL. Developers can use this function in the `WHERE` clause to filter documents by the state defined in the document lifecycle as “Deleted State”.

</ReleaseNote>