**Source URL:** https://limited.veevavault.dev/rn/20r1.md
# Vault Developer Release Notes
We are pleased to bring you the following additions and enhancements to Developer Portal features in 20R1.
## Developer Features in 20R1 {#developer-features-in-20r1}
We are pleased to bring you the following additions and enhancements to Developer Portal features in 20R1. For issues fixed in this release, view the "Developer Features" category of the [fixed issues list in Vault Help](https://platform.veevavault.help/en/lr/60296).
### REST API v20.1 {#rest-api-v201}
REST API features added in 20R1 only affect API v20.1, unless otherwise noted.
#### Enablement Change: Standard Metrics (Non-Mandatory) {#20r1-enablement-change-standard-metrics}
Three fields, *Global Content Type* (`global_content_type__v`), *Content Creation Currency* (`content_creation_currency__v`), and *Content Creation Cost* (`content_creation_cost__v`) will be turned on for all PromoMats Vaults in the 19R3.5 release. If these optional fields are excluded, Vault will automatically populate any documents created through the API with the default value for these fields, or with “Not Specified" if no default exists.
Learn more about [PromoMats Standard Metrics in Vault Help](https://commercial.veevavault.help/en/lr/58143).
#### Reassign Multi-Document Workflow Task Parameter Format Change {#20r1-reassign-multi-document-workflow-task-parameter-format-change}
When reassigning a task to another user in a Multi-document Workflow instance, the parameter used to identify the new assignee (`task_assignee__v`) has been updated to the format `user:{id}`. For example, to reassign a multi-document workflow task to a user with ID 12345, you would input this ID as `user:12345`.
This parameter is now more consistent with the format used elsewhere in multi-document and object workflow, as it also disambiguates between user and group IDs.
#### Object Record User Actions APIs: Add Lifecycle State to ‘action_name’ Parameter {#20r1-object-record-user-actions-apis-add-lifecycle-state-to-action-name-parameter}
With this enhancement, API users initiating an object record user action will need to specify the state name. This prevents ambiguity if there are duplicate user action names within a lifecycle, which may cause errors in earlier API versions.
View these endpoints in the [v20.1 API Reference](/vault-api/api-reference/20.1/object-lifecycle-workflows/object-record-user-actions).
#### VPK Component Dependency Validation {#20r1-vpk-component-dependency-validation}
This feature allows an Admin or configuration specialist to validate a configuration migration package prior to importing and deploying it. The **Validate Package** API response now includes information about the dependent components, whether they are required, and whether they exist in the package or the target Vault.
View this endpoint in the [v20.1 API Reference](/vault-api/api-reference/20.1/configuration-migration/validate-package).
#### Auth API Limits {#20r1-auth-api-limits}
With this feature, the **Authentication** API introduces burst rate limiting. This limits the number of API calls a Vault can receive within a short time period. The authentication API burst limit is 20 calls within one minute, tracked based on the domain and user name provided in the API call.
Unlike daily limits, the authentication API limit is not calculated on a rolling basis. Instead, this limit is calculated at fixed, one-minute intervals.
The Authentication API rate limit is applicable only to calls made to `/api/{version}/auth` with a user name and password. The limit does not apply to SAML/SSO or OAuth authentication.
Learn more about [API Rate Limits](/docs/#api_rate_limits).
#### Record Migration Mode for Configuration Migration Packages {#20r1-record-migration-mode-for-configuration-migration-packages}
Record Migration Mode allows configuration specialists to use outbound packages with dataset items to create object records in non-initial state.
This feature introduces a new field, *Record Migration Mode* (`record_migration_mode__sys`) to the *Inbound Package Data* (`vault_data_package__v`) and *Dataset Item* (`dataset_item__sys`) objects.
#### Record Migration Mode for Loader REST API {#20r1-record-migration-mode-for-loader-rest-api}
Record Migration Mode now allows integration specialists to use Loader REST API to create object records in non-initial state.
Learn more about [Loader REST API](/vault-api/api-reference/20.1/vault-loader).
#### idParam for Loader REST API {#20r1-idparam-for-loader-rest-api}
This feature allows integration specialists to specify the `idParam` that can be used with an upsert, update, and delete action to identify the field that will be used to identify the record.
Learn more about [Loader REST API](/vault-api/api-reference/20.1/vault-loader).
#### Periods Supported for client_id {#20r1-periods-supported-for-client_id}
Every Vault REST API call can accept an optional client ID to represent an external integration client. You can provide this data via a query parameter called `client_id` or HTTP Header called `X-VaultAPI-ClientID`.
Previously, underscores and hyphens were the only special characters allowed in a valid client ID. With this release, a valid client ID may also contain periods.
Learn more about [client_id](/docs/#Client_ID).
#### Veeva Safety: Import Narrative REST API {#20r1-veeva-safety-import-narrative-rest-api}
This feature introduces a publicly accessible API for importing a Veeva Safety Case narrative. This will assist with non-E2B database migrations to Veeva Safety.
Learn more about [Import Narrative REST API](/vault-api/api-reference/20.1/vault-query-language-vql).
### Vault Java SDK {#vault-java-sdk}
#### Object Metadata Service {#20r1-object-metadata-service}
With `ObjectMetadataService`, Vault Java SDK developers can now retrieve Vault object and field metadata without having to rely on HTTP callouts to the Vault REST API. The service enables fetching of object attributes, such as name or label, and also includes the ability to return all, required, or unique object fields. Developers can also use the service to retrieve field-level information, including requiredness, uniqueness, copy availability, among other metadata.
Learn more in the [Javadocs](https://repo.veevavault.com/javadoc/vault-sdk-api/19.3.5/docs/api/com/veeva/vault/sdk/api/data/package-summary.html).
#### Spark Message Delivery Event Handler SDK Interface {#20r1-spark-message-delivery-event-handler-sdk-interface}
The `MessageDeliveryEventHandler` interface allows developers to handle undeliverable Spark messages. Any classes implemented using this interface can be assigned to an *Outbound Queue*. The class assigned to the queue will be run anytime a Spark message can't be delivered to its destination.
A *Message Delivery Event Handler User* is required to ensure auditable events triggered by `MessageDeliveryEventHandler` run on behalf of a named user. By default, handler code executes with System-level access, identified in audit logs as *System on behalf of `{originatingUser}`*, where `{originatingUser}` is the *Spark Message Delivery Event Handler User*.
Learn more about [Message Delivery Event Handlers](/vault-sdk/sdk-integrations/vault-integrations/#Message_Delivery_Event_Handler).
#### Integration Rule Service with Custom Error Reporting {#20r1-integration-rule-service-with-custom-error-reporting}
Previously, it was not possible for custom Spark Integrations to access the error details returned by `IntegrationRuleService`. In this release, we have created a new set of Integration Rule Services that provide custom error reporting.
#### SDK Create Document & Versions {#20r1-sdk-create-document-versions}
This feature adds new Vault Java SDK functionality which enables developers to create new documents and versions for existing documents with `DocumentService`. For example, developers can:
* Set the source, rendition, or attachment file of an existing document as the source, rendition, or attachment file of a new document or version.
* Retrieve files from a document in any Vault the developer can access.
When creating new document versions, document fields do not automatically inherit values from the prior version. This means developers must manually set all document fields on new versions. Developers must also manually set the version number and lifecycle status, similar to creating multiple new versions in migration mode. In addition, creating new document versions in the Vault Java SDK has the same [limitations](https://platform.veevavault.help/en/lr/54028) as creating multiple versions via the API in document migration mode. The method to create multiple document versions is named `migrateDocumentVersions` to reflect these limitations.
Learn more in the [Javadocs](https://repo.veevavault.com/javadoc/vault-sdk-api/19.3.4/docs/api/com/veeva/vault/sdk/api/document/package-summary.html).
#### Memory Limit Accuracy {#20r1-memory-limit-accuracy}
With this feature, the Vault Java SDK enables developers to write code that better measures memory allocation and deallocation. This enhancement helps developers better manage memory consumption so code stays within the maximum memory limit of 40MB imposed by the Vault Java SDK.
Specifically, this feature introduces a concept of User-defined Service (UDS). Much like core SDK services, developers now have the ability to code UDS. These services are stateless singletons whose methods, once exited, give the memory allocated in the method back toward the limit. The only thing that counts toward the limit is the size of the method return value.
Learn more about [Memory Limit Accuracy & User-defined Services](/vault-sdk/shared-code/uds).
#### Record Workflow Action Enhancement: Display Custom Participant Group on Object Workflow Start Dialog {#20r1-record-workflow-action-enhancement-display-custom-participant-group-on-object-workflow-start-dialog}
The new `WorkflowEvent`, `DISPLAY_PARTICIPANTS`, enables Vault Java SDK developers to implement record workflow actions that determine the participants of a workflow with the option to display those participants on the workflow start dialog. This allows Vault Admins to see a grouping of workflow participants before they start the workflow.
`DISPLAY_PARTICIPANTS(WorkflowStepType.START)` occurs when displaying participants with a custom action on a workflow start step, prior to workflow instance creation.
Learn more in the [Javadocs](https://repo.veevavault.com/javadoc/vault-sdk-api/19.3.4/docs/api/com/veeva/vault/sdk/api/workflow/package-summary.html).
#### Document Type Support for Reference Lookups {#20r1-document-type-support-for-reference-lookups}
This feature is geared towards developers building Spark integrations. It is common to have Vaults with document types that are the same but with different names, especially across Vault families. With document-type reference lookups, Spark-integration developers can now map source document types to target document types, avoiding the need to hard code the mappings.
Learn more about [Reference Lookups](/vault-sdk/sdk-integrations/spark-messaging/integration-rules).
### MDL {#mdl}
#### Inherited Document Type Group Property for Doctype Component {#20r1-inherited-document-type-group-property-for-doctype-component}
To clarify when a `Doctype` inherits its `doctype_group` from the parent document type, this feature introduces the `inherit_doctype_groups` attribute to the `Doctype` component. If `true`, the `doctype_group` value is inherited from the parent `Doctype`. If `false`, the `Doctype` does not inherit the value and has no `doctype_group` value set.
#### Spark Message Delivery Event Handler SDK Interface {#20r1-spark-message-delivery-event-handler-sdk-interface-mdl}
The `MessageDeliveryEventHandler` interface allows developers to handle undeliverable Spark messages. Any classes implemented using this interface can be assigned to an *Outbound Queue*. The class assigned to the queue will be run anytime a Spark message can't be delivered to its destination.
The feature introduces two new attributes, `message_delivery_event_handler` and `message_delivery_event_handler_user`, to the `Queue` component. These attributes can be set on an outbound queue once the handler code has been deployed to Vault. The new `Messagedeliveryeventhandler` component is referenced by the `message_delivery_event_handler` attribute.
#### Document Type Support for Reference Lookups {#20r1-document-type-support-for-reference-lookups-mdl}
With document-type reference lookups, Spark-integration developers can now map source document types to target document types, avoiding the need to hard code the mappings.
To support the new reference lookup type, the `Fieldrule` component's `reference_lookup_type` attribute now includes a `documenttype` value.
#### Add single_instance_states attribute to Jobmetadata Component {#20r1-add-single_instance_states-attribute-to-jobmetadata-component}
SDK Jobs can now be configured to only allow one instance of that job to be in a given state at any time. The `Jobmetadata` component’s `single_instance_states` attribute accepts a value of `scheduled`, `queued`, or `running`, depending on which states of the job need to be restricted to one instance at a time. SDK Jobs that attempt to enter into a state that only allows a single instance will be blocked.
### VQL {#vql}
#### VQL No Longer Truncates Trailing Zeros on Number & Currency {#20r1-vql-no-longer-truncates-trailing-zeros-on-number-currency}
In VQL versions v19.3 and below, VQL truncates trailing zeros on Number and Currency fields. For example, if your Vault has the field `vacation_days__c` whose value was entered by a user as 10.00, VQL returns 10 for `vacation_days__c`.
Now in VQL versions v20.1+, Number fields appear exactly as the user entered them, so VQL will return 10.00 for `vacation_days__c`.
#### Enhanced Synonym Support in VQL {#20r1-enhanced-synonym-support-in-vql}
This feature enhances the synonym support in VQL when used with content searches. The enhancement is only applicable when using VQL `FIND` clause with parentheses. For example, `FIND (‘cholesterol’)` would find documents and objects containing the word cholesterol as well as any synonyms for cholesterol configured in that Vault.
Learn more about [Synonyms in VQL](/vql/references/search-specifications/search-matching-behavior).