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

# Vault Developer Release Notes

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

## Developer Features in 19R3 {#developer-features-in-19r3}

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

<ReleaseNote id="19r3-scalable-overlay-processing" label="September 27, 2019" app_family="platform" version="19r3">### Scalable Overlay Processing {#19r3-scalable-overlay-processing}

In this release, we will no longer process overlays for a Vault on that Vault's POD. Instead, overlay processing will occur on a rendition server. This change will not introduce any difference in functionality, but should improve performance when downloading viewable renditions with overlays applied.

In all versions of the API, the following endpoints may see changes in performance:

* [Download Document Rendition File](/vault-api/api-reference/19.3/documents/document-renditions/download-document-rendition-file)

* [Download Document Version Rendition File](/vault-api/api-reference/19.3/documents/document-renditions/download-document-version-rendition-file)

If you notice any performance problems related to overlays in your integrations, please log a ticket with Veeva Support.

</ReleaseNote>

### REST API v19.3 {#19r3-rest-api-v193}

<ReleaseNote id="19r3-limited-release-sandboxes" label="Dec 6, 2019" app_family="platform" version="19r3">### Limited Release Sandboxes {#19r3-limited-release-sandboxes}

This feature allows API users to create and manage a Limited Release sandbox from a Vault on General Release. We’ve introduced a new attribute, `release`, which describes a sandbox Vault's release and can be used as part of the request to create a sandbox. API users can set this attribute to ‘general’ or ‘limited’ while requesting a new sandbox. If omitted, the default value is set to match the release type of the Vault requesting the sandbox.

<Endpoint path="/api/{version}/objects/sandbox" method="POST"></Endpoint></ReleaseNote>
<ReleaseNote id="19r3-download-notes-to-csv" label="September 27, 2019" app_family="platform" version="19r3">### Download Notes to CSV {#19r3-download-notes-to-csv}

This feature allows users to download annotations from Vault documents in a CSV file with a new public API. The action is available to users with *View Content* permission whenever the document has a viewable rendition and one or more annotations.

<Endpoint path="/api/{version}/objects/documents/{doc_id}/versions/{major_version}/{minor_version}/doc-export-annotations-to-csv" method="GET"></Endpoint>View this endpoint in the [v19.3 API Reference](/vault-api/api-reference/19.3/documents/document-annotations/retrieve-document-version-notes-as-csv).

</ReleaseNote>
<ReleaseNote id="19r3-record-bulk-attachments-api" label="September 27, 2019" app_family="platform" version="19r3">### Record Bulk Attachments API {#19r3-record-bulk-attachments-api}

This feature allows API users to create, update, or delete object record attachments in bulk with a JSON or CSV input file. Users must first load the attachments to the FTP staging server before creating attachments.

<Endpoint path="/api/{version}/vobjects/{object_name}/attachments/batch" method="POST"></Endpoint><Endpoint path="/api/{version}/vobjects/{object_name}/attachments/batch" method="PUT"></Endpoint><Endpoint path="/api/{version}/vobjects/{object_name}/attachments/batch" method="DELETE"></Endpoint>If you use the API to create an attachment which already exists, Vault uploads it as a new version of the existing attachment. View these endpoints in the [v19.3 API Reference](/vault-api/api-reference/19.3/vault-objects/object-record-attachments/create-multiple-object-record-attachments).

</ReleaseNote>
<ReleaseNote id="19r3-remove-ability-to-create-drafts-for-checked-out-documents" label="October 18, 2019" app_family="platform" version="19r3">### Remove Ability to Create Drafts for Checked Out Documents {#19r3-remove-ability-to-create-drafts-for-checked-out-documents}

The [Create Single Document Version](/vault-api/api-reference/19.3/documents/update-documents/create-single-document-version) endpoint will no longer allow users to create drafts of documents which are currently checked-out. Attempting to do so will throw an `OPERATION_NOT_ALLOWED` error.

Previous versions of the API and the bulk [Create Multiple Document Versions](/vault-api/api-reference/19.3/documents/update-documents/create-multiple-document-versions) API still allow this behavior.

</ReleaseNote>
<ReleaseNote id="19r3-user-pending-state" label="September 27, 2019" app_family="platform" version="19r3">### User Pending State {#19r3-user-pending-state}

This feature adds a new *Pending* state to the *Vault Membership* lifecycle on the *User* object. Welcome emails can be delayed until the activation date.

When adding a user via the *User* object, the new *Activation Date* field can be set to a future date. Adding an activation date sets the user’s initial state to *Pending*. A new job will run daily to make any pending users active according to their activation date.

</ReleaseNote>
<ReleaseNote id="19r3-user-action-to-promote-person-to-user" label="September 27, 2019" app_family="platform" version="19r3">### User Action to Promote Person to User {#19r3-user-action-to-promote-person-to-user}

*Release Notes updated for accuracy September 2, 2020*

In this release, there is a new user action available on *Person* records to **Promote to User**. This action streamlines the creation of a corresponding *User* record for the *Person record*. The newly created user will be automatically linked to the person via the user reference field on person.

To do this through the existing <del>**Create User**</del> **Create Object Records** API, a `person__sys` record ID can be specified as the <del>`source_person__v`</del> `source_person_id__v` field value. The **Source Person** field on a user is specific to Veeva Clinical.

</ReleaseNote>
<ReleaseNote id="19r3-restrict-delegate-access" label="August 23, 2019" app_family="platform" version="19r3">### Restrict Delegate Access {#19r3-restrict-delegate-access}

With this feature, organizations can define groups of users who can delegate access only among themselves.

Admins can create and update groups that leverage this functionality by setting the optional parameter `allow_delegation_among_members__v` to  `true`. By default, this attribute is set to `false`.

Additionally, all requests to retrieve information about groups will include the `allow_delegation_among_members__v` field.

See these new parameters in the [v19.3 API Reference](/vault-api/api-reference/19.3/groups).

</ReleaseNote>
<ReleaseNote id="19r3-multidocument-workflow-remove-documents-from-envelope-based-on-outcome" label="October 18, 2019" app_family="platform" version="19r3">### Multi-Document Workflow: Remove Documents from Envelope Based on Outcome {#19r3-multidocument-workflow-remove-documents-from-envelope-based-on-outcome}

This feature allows workflow initiators to remove one or more documents from an active Multi-Document Workflow with a new `removecontent` workflow action. Documents removed from the workflow will return to the configured workflow *Cancelled* state configured on the document lifecycle state. Users will be able to get details regarding the remove content action as well as post the list of documents that should be removed.

Use the new **Retrieve Workflow Action Details** on the `removecontent` action to retrieve any required parameters to execute the action:

<Endpoint path="/api/{version}/objects/objectworkflows/{workflow_id}/actions/{workflow_action}" method="GET"></Endpoint>To remove documents from an envelope in an active multi-document workflow, use the existing [Initiate Workflow Action](/vault-api/api-reference/19.3/object-lifecycle-workflows/workflows/initiate-workflow-action) endpoint and include the `document__sys` to remove. For example:

<Endpoint path="/api/v19.3/objects/objectworkflows/801/actions/removecontent?document__sys=1,2,3" method="POST"></Endpoint></ReleaseNote>
<ReleaseNote id="19r3-multidocument-workflow-constrain-multidocument-workflow-based-on-document-status-field-values" label="September 27, 2019" app_family="platform" version="19r3">### Multi-Document Workflow: Constrain Multi-Document Workflow Based on Document Status & Field Values {#19r3-multidocument-workflow-constrain-multidocument-workflow-based-on-document-status-field-values}

This feature adds additional validation when [Initiating a Multi-Document Workflow](/vault-api/api-reference/19.3/multi-document-workflows/initiate-multi-document-workflow). If the content documents are not in the relevant state or does not meet configured field conditions, the API returns `INVALID_DATA` with  the specific documents that did not meet the criteria.

In previous versions of the API, these invalid documents are ignored and the operation continues with all valid documents.

</ReleaseNote>
<ReleaseNote id="19r3-document-lifecycle-user-actions-api-enhancements" label="October 18, 2019" app_family="platform" version="19r3">### Document Lifecycle User Actions API Enhancements {#19r3-document-lifecycle-user-actions-api-enhancements}

This feature introduces enhancements to three document lifecycle API endpoints. Starting from v19.3, the API returns additional field data and uses new values for `name__v` that are more consistent with the rest of Vault API. For example, the name of the *Due Date* field is `dueDate` in v19.2, but is `date_control__c` in v19.3+.

Affected endpoints:

* **Retrieve User Actions**:

<Endpoint path="/api/{version}/objects/{documents_or_binders}/(id}/versions/{major_version}/{minor_version}/lifecycle_actions" method="GET"></Endpoint>
* **Retrieve Entry Criteria**:

<Endpoint path="/api/{version}/objects/{documents_or_binders}/(id}/versions/{major_version}/{minor_version}/lifecycle_actions/{name__v}/entry_requirements" method="GET"></Endpoint>
* **Initiate User Action**:

<Endpoint path="/api/{version}/objects/{documents_or_binders}/{id}/versions/{major_version}/{minor_version}/lifecycle_actions/{name__v}" method="PUT"></Endpoint></ReleaseNote>
<ReleaseNote id="19r3-api-usage-logs-to-include-request-duration" label="September 27, 2019" app_family="platform" version="19r3">### API Usage Logs to Include Request Duration {#19r3-api-usage-logs-to-include-request-duration}

This feature adds a *duration* column to the API Usage Logs. The column shows the time it takes an API request to execute in Vault, measured in milliseconds. Note the duration does not include transport times between Vault and the client.

</ReleaseNote>
<ReleaseNote id="19r3-export-full-audit-trails" label="August 23, 2019" app_family="platform" version="19r3">### Export Full Audit Trails {#19r3-export-full-audit-trails}

This feature allows customers to gain access to a complete export of their audit logs. Previously, you could only retrieve the last 30 days of events. Document, Object, System, Login, and Domain audit logs are available.

The Retrieve Audit Details API supports a new parameter, `all_dates`. When set to `true`, the API starts a job to export the full audit trail with the same formatting as exports initiated through the UI. When the job is complete, the admin receives an email containing links to the zipped files, organized by year.

View this new parameter in the [v19.3 API Reference](/vault-api/api-reference/19.3/logs/audit/retrieve-audit-details).

</ReleaseNote>
<ReleaseNote id="19r3-automated-claims-linking" label="September 27, 2019" app_family="platform" version="19r3">### Automated Claims Linking {#19r3-automated-claims-linking}

Automated Claims Linking automates the generation of reference links on claim statements in promotional materials. Claims and associated references are configured and approved in Veeva PromoMats and applied to documents, where users can quickly review and accept them.

Users can also now retrieve anchor IDs via the Document Annotations API.

<Endpoint path="/api/{version}/objects/documents/{doc_id}/anchors" method="GET"></Endpoint>View this endpoint in the [v19.3 API Reference](/vault-api/api-reference/19.3/documents/document-annotations/retrieve-anchor-ids).

</ReleaseNote>
<ReleaseNote id="19r3-clinical-person-organization-migration-enablement-change" label="October 18, 2019" app_family="platform" version="19r3">### Clinical: Person & Organization Migration Enablement Change {#19r3-clinical-person-organization-migration-enablement-change}

This feature enables the Person & Organization Migration feature delivered in 19R2 for all customers. The Person & Organization Migration introduces a series of data model changes to your Veeva Clinical application objects. These changes serve to streamline the process for creating Person, Study Person, and Study Organization object records.

</ReleaseNote>
<ReleaseNote id="19r3-veeva-safety-receive-e2b-api" label="October 18, 2019" app_family="platform" version="19r3">### Veeva Safety: Receive E2B API {#19r3-veeva-safety-receive-e2b-api}

This feature introduces a publicly accessible API for exchanging E2B(R3) files with trusted partners in Veeva Safety. Partners can send an E2B file using the REST API, which automatically initiates E2B import into an Adverse Event Report. After a successful operation, you can retrieve an E2B(R3) compliant ACK.

<aside class="notice">In [24R3](/rn/24r3/#OOU0000000L4009), this endpoint was deprecated in all versions.</aside></ReleaseNote>

### VQL {#19r3-vql}

<ReleaseNote id="19r3-document-field-checkout_flavor__v-replaced-with-checkout_type__sys" label="August 23, 2019" app_family="platform" version="19r3">### Document Field checkout_flavor__v replaced with checkout_type__sys {#19r3-document-field-checkout_flavor__v-replaced-with-checkout_type__sys}

To support additional document checkout types, the standard document text field `checkout_flavor__v` has been deprecated and replaced with a new system picklist field `checkout_type__sys`. The `checkout_flavor__v` field was hidden and not visible to users in the UI, but it was queryable using VQL. Customers must update integrations which queried `checkout_flavor__v` with VQL.

</ReleaseNote>
<ReleaseNote id="19r3-state-type-function-for-objects" label="August 23, 2019" app_family="platform" version="19r3">### State Type Function for Objects {#19r3-state-type-function-for-objects}

This feature enhances VQL by providing a new `STATETYPE()` function that exposes all state types configured in object lifecycles. This function can be used in the `WHERE` clause to filter the objects by specific lifecycle states.

</ReleaseNote>
<ReleaseNote id="19r3-task-instructions" label="August 23, 2019" app_family="platform" version="19r3">### Task Instructions {#19r3-task-instructions}

When a workflow owner assigns a task to a user, they can choose to enter instructions. A new field, `task_instructions__v`, is now available in VQL. This field retrieves the contents of the field from all task steps within document workflows in a Vault.

</ReleaseNote>

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

<ReleaseNote id="19r3-spark-integration-management" label="September 27, 2019" app_family="platform" version="19r3">### Spark Integration Management {#19r3-spark-integration-management}

This feature enhances Spark Integrations by allowing administrators to define groupings (Integrations) of business processes (Integration Points) that work together to achieve the integration goals. Developers can leverage the Integrations and Integration Points along with Integration Rules to create specific business processing rules and to route any user exception messages to the appropriate personnel for resolution.

Learn more about [Integration and Integration Point records in Vault Help](https://platform.veevavault.help/en/lr/57405).

</ReleaseNote>
<ReleaseNote id="19r3-spark-user-exceptions" label="September 27, 2019" app_family="platform" version="19r3">### Spark User Exceptions {#19r3-spark-user-exceptions}

Vault provides a new *User Exception Message* object and its child object, *User Exception Item*, to help Business Admins track and resolve any errors that occur with your integrations. Vault Java SDK developers can leverage these objects inside Spark message processors to create custom exception messages displayed to Business Admins.

For example, if either end of your integration fails to process an incoming message, your custom SDK logic creates a *User Exception Message* record to capture the failure and display information to a Business Admin. This record can contain information for how to troubleshoot, what action is necessary, who to contact if the failure persists, and so on.

Learn more about [developing user exception messages](/vault-sdk/sdk-integrations/spark-messaging/user-exception-messages).

</ReleaseNote>
<ReleaseNote id="19r3-message-catalog" label="September 27, 2019" app_family="platform" version="19r3">### Message Catalog {#19r3-message-catalog}

This feature enables Vault Java SDK developers to provide a localized experience for the end user. Vault administrators can translate the developer-created messages into any Vault supported language.

With this feature, we've added the `Messagegroup` component and `Message` subcomponent to MDL.

Learn more about using the [Message Catalog](/vault-sdk/entry-points/sdk-message-catalog).

</ReleaseNote>
<ReleaseNote id="19r3-remove-limit-for-maximum-allowed-userdefined-classes" label="August 23, 2019" app_family="platform" version="19r3">### Remove Limit for Maximum Allowed User-Defined Classes {#19r3-remove-limit-for-maximum-allowed-userdefined-classes}

With this feature, the Java SDK no longer has a maximum limit on the number of user-defined classes (UDCs). Users can upload as many UDCs as needed, given your Vault does not reach the 1,000 source file limit.

Learn more about [Vault Java SDK limits and restrictions](/vault-sdk/references/limits-restrictions).

</ReleaseNote>
<ReleaseNote id="19r3-thread-sleep-method" label="September 27, 2019" app_family="platform" version="19r3">### Thread Sleep Method {#19r3-thread-sleep-method}

With this feature, Vault Java SDK exposes a new method by which developers can put a thread to sleep for a specified period of time, measured in milliseconds. This method is available in the new Vault Java SDK `RuntimeService`. The method is similar to the Java `Thread.sleep()` method.

View this new method in the [Javadocs](https://repo.veevavault.com/javadoc/vault-sdk-api/19.2.4/docs/api/com/veeva/vault/sdk/api/core/RuntimeService.html).

</ReleaseNote>
<ReleaseNote id="19r3-job-processors" label="September 27, 2019" app_family="platform" version="19r3">### Job Processors {#19r3-job-processors}

In the Java SDK, there is a new `runJob` method in `JobService`, which returns the new `JobRunResult` object. You can use the `getJobId()` method on this object to get the job ID.

Previous to this feature, there was no way to get the job ID through the Java SDK.

</ReleaseNote>
<ReleaseNote id="19r3-clear-all-values-from-requestcontext" label="October 31, 2019" app_family="platform" version="19r3">### Clear All Values from RequestContext {#19r3-clear-all-values-from-requestcontext}

In this release, we've added a new `clear()` method to `RequestContext`, which allows developers to remove all values from the request context with one method call. Previously, developers would need to remove items one at a time with multiple calls to `removeValue(String name)`.

</ReleaseNote>
<ReleaseNote id="19r3-object-document-lifecycle-reference-lookups" label="August 23, 2019" app_family="platform" version="19r3">### Object & Document Lifecycle Reference Lookups {#19r3-object-document-lifecycle-reference-lookups}

Previously, integration rules using reference lookups could only select `LIFECYCLE_STATE`, allowing a lookup for either document or object lifecycle states. With this feature, we are deprecating `LIFECYCLE_STATE` while adding `OBJECT_LIFECYCLE_STATE` and `DOCUMENT_LIFECYCLE_STATE`, allowing developers to be more specific. All existing Vault extensions using `LIFECYCLE_STATE` are still supported, but you cannot use this for any new extensions. This option will no longer appear in the Vault UI, even for existing extensions.

View this [Enum in the Javadocs](https://repo.veevavault.com/javadoc/vault-sdk-api/19.2.4/docs/api/com/veeva/vault/sdk/api/integration/ReferenceLookupType.html).

</ReleaseNote>
<ReleaseNote id="19r3-debug-log-for-application-messages" label="September 27, 2019" app_family="platform" version="19r3">### Debug Log for Application Messages {#19r3-debug-log-for-application-messages}

This feature enables Vault applications to include messages in the debug log. The debug messages generated by the application can be distinguished by the String `[standard]` prepended to each message.

Learn more about the [Debug Log](/vault-sdk/troubleshooting-runtime-errors/debug-log).

</ReleaseNote>
<ReleaseNote id="19r3-write-resource-usage-data-to-debug-log" label="August 23, 2019" app_family="platform" version="19r3">### Write Resource Usage Data to Debug Log {#19r3-write-resource-usage-data-to-debug-log}

This feature adds a new API in `LogService`, `logResourceUsage(String message)`, which allows users to log the total amount of resources that their SDK code has used thus far which counts towards their resource limit.

For example, this is what output would look like in the Debug Log when this method is called with a message `"USAGE"`:

`INFO "USAGE": CPU(ns)={CPUTIME} elapsed(ms)={ELAPSEDTIME} memory(b)={MEMORYUSAGE}`

When an empty message or null is passed in, the output would look like:

`INFO CPU(ns)={CPUTIME} elapsed(ms)={ELAPSEDTIME} memory(b)={MEMORYUSAGE}`

View this new [method in the Javadocs](https://repo.veevavault.com/javadoc/vault-sdk-api/19.2.4/docs/api/com/veeva/vault/sdk/api/core/LogService.html).

</ReleaseNote>
<ReleaseNote id="19r3-deallocate-memory-when-exiting-nested-sdk-code" label="August 23, 2019" app_family="platform" version="19r3">### Deallocate Memory When Exiting Nested SDK Code {#19r3-deallocate-memory-when-exiting-nested-sdk-code}

This feature enhances the mechanism which tracks the SDK memory allocation limit. The limit now resets to the previous value after each Vault extension execution, even if it is not a top-level extension.

The 40MB memory allocation limit applies to SDK Vault extensions and its nested Vault extensions. Since memory allocations made in one Vault extension cannot be "retained" beyond its execution, memory allocations made in a Vault extension will now be "discounted" from usage (that counts towards limit) after its execution, regardless of that particular extension being nested or top level.

Learn more about [memory limits](/vault-sdk/references/limits-restrictions).

</ReleaseNote>
<ReleaseNote id="19r3-new-whitelisted-methods" label="September 27, 2019" app_family="platform" version="19r3">### New Whitelisted Methods {#19r3-new-whitelisted-methods}

With this release, we've added two new methods to the JDK Whitelist:

* `Map.Entry getKey()`

* `Map.Entry getValue()`

The following methods were added in 19R1, but were not included in the 19R1 release notes:

* `ThreadLocalRandom current()`

* `int nextInt()`

* `int nextInt(int bound)`

* `int nextInt(int origin, int bound)`

* `long nextLong()`

* `long nextLong(long bound)`

* `long nextLong(long origin, long bound)`

* `float nextFloat()`

* `double nextDouble()`

* `double nextDouble(double bound)`

* `double nextDouble(double origin, double bound)`

You can download the [full JDK Whitelist from our documentation](/vault-sdk/references/limits-restrictions/#JDK_Allowlist).

</ReleaseNote>

### MDL {#19r3-mdl}

<ReleaseNote id="19r3-changes-to-docfielddependency" label="September 27, 2019" app_family="platform" version="19r3">### Changes to Docfielddependency {#19r3-changes-to-docfielddependency}

Previously, VPKs would fail if they contained a `Docfielddependency` whose `docfield_value` or `deprule_docfield_values` referenced a value that contained a comma character (`,`). For example, a country record with the name "Tanzania, United Republic of".

To fix this issue, we've deprecated the following attributes on `Docfielddependency`:

* `docfield_value`

* `deprule_docfield_values`

The following new attributes replace the deprecated attributes:

* `docfield_multi_value`

* `deprule_docfield_multi_values`

The deprecated attributes are still supported for existing integrations and VPKs, but new integrations and VPKs must use the new attributes. Old VPKs which failed due to a comma in a label will still fail until a new VPK is generated with the new attributes.

</ReleaseNote>
<ReleaseNote id="19r3-relate-multiple-records-complex-join-related-sections" label="September 27, 2019" app_family="platform" version="19r3">### Relate Multiple Records: Complex Join Related Sections {#19r3-relate-multiple-records-complex-join-related-sections}

This feature allows Business Administrators to enable users to select multiple records in a complex join related section.

We've added new MDL attribute called `multi_select`. This attribute is applicable for only complex Many-to-Many join objects, and is `false` by default. When this attribute value is `true`, end-users in the Vault UI can select multiple records in a complex join related section.

</ReleaseNote>
<ReleaseNote id="19r3-object-state-types" label="August 23, 2019" app_family="platform" version="19r3">### Object State Types {#19r3-object-state-types}

This feature enables developers to associate an object lifecycle state with an object state type.  State types are important as some Vault functionality that interacts with object lifecycle states across lifecycles or Vaults require this mapping to be provided. To support this feature, we have added two new components.

The `Lifecyclestatetype` component returns data for all available object lifecycle state types within a Vault.

The `Lifecyclestatetypeassociation` joins a `Lifecyclestatetype` record with an `Objectlifecycle` record.

On the `Objectlifecycle` component, we are deprecating the `labeled_states` and `state_labels` attributes in favor of the new components. We will also revive the `starting_state` attribute. The deprecated components will continue to work in existing integrations.

</ReleaseNote>
<ReleaseNote id="19r3-automated-claims-linking" label="September 27, 2019" app_family="platform" version="19r3">### Automated Claims Linking {#19r3-automated-claims-linking}

Automated Claims Linking automates the generation of reference links on claim statements in promotional materials. Claims and associated references are configured and approved in Veeva PromoMats and applied to documents, where users can quickly review and accept them.

This feature introduces two new attributes, `enable_suggested_link_source` and `enable_suggested_link_target`, to the MDL `Doctype` component. These Booleans allow you to enable or disable this feature on a Doctype.

</ReleaseNote>