**Source URL:** https://general.veevavault.dev/rn/21r1.md
# Vault Developer Release Notes
We are pleased to bring you the following additions and enhancements to Developer Portal features in 21R1.
## Developer Features in 21R1 {#developer-features-in-21r1}
We are pleased to bring you the following additions and enhancements to Developer Portal features in 21R1. REST API features added in 21R1 only affect API v21.1, unless otherwise noted.
## Service Announcements {#service-announcements}
### Veeva Vault TLS Cipher Suite Changes {#21r1-veeva-vault-tls-cipher-suite-changes}
Beginning with the 21R1 release, Vault will no longer support the following cipher:
* TLSv1.2/DHE-RSA-AES256-GCM-SHA384
All customers with affected integrations will be contacted directly by Veeva Services prior to any changes so that they can test their integrations. Testing can be performed in a limited release sandbox.
Learn more about [Veeva Vault cipher suite changes](/docs/tls/cipher).
### Maximum Session Duration of 48 Hours {#21r1-maximum-session-duration-of-48-hours}
As part of continuous security enhancements, the maximum session duration of an active session is now 48 hours starting from 21R1.0. Previously, active sessions had no maximum duration.
A session is considered “active” as long as some activity (UI / API) happens within 48 hours. After 48 hours of activity, a session is no longer valid and a new session must be obtained. This is in addition to sessions which become inactive from inactivity or major security changes such as password changes.
For custom integrations based on our REST APIs, we recommend the reuse of the session ID obtained after login to execute multiple API requests. However, a best practice is to make sure that your integration code catches any invalid session exceptions to obtain a new session as needed. Integrations that do not follow this best practice may be impacted by the 21R1.0 change in maximum session duration. Learn more about [best practices for session management](/docs/#Session_Mangement).
Note that this change will be delivered with the 21R1.0 B release (April 16th), and not the A release (April 9th).
## Global Changes {#global-changes}
### Rich Text Fields for Vault Objects {#21r1-rich-text-fields-for-vault-objects}
In this release we’ve added a new *Rich Text* field type to Vault objects. This new field type allows for text values with formatting stored as HTML markup, such as bold and italic. Both the full-markup value and markup-free value for this type of field are available through the usual APIs: Vault Object APIs, VQL, SDK, Loader, etc. Rich text is not supported for Merge Fields. Learn more about [Rich Text fields](/docs/#RichTextAPI).
Additionally, users can convert Long Text fields to Rich Text with MDL. This is a one-way conversion which cannot be undone and may affect your existing custom integrations. Learn more about [conversion from Long Text to Rich Text](/mdl/documentation/mdl-commands/alter#Multi_Value).
### Role Permissions {#21r1-role-permissions}
With role permissions, application roles have a new permission set attribute. When a role is assigned to a user, the related permissions are assigned to the user in addition to security profile permissions.
Role permissions introduce the concept of a role assignment to a user, as opposed to roles applied only in the context of specific documents or object records. We’ve added a new platform object `user_role__sys` to persist user role assignments.
`User_role__sys` Object records can be created, edited, or deleted by a user with the Object permissions and also require the *Admin: Security: Users: Manage* user object permission. The Object can be accessed using the standard Vault Object REST APIs.
This feature introduces the `Rolepermissionset` MDL component type, which stores the relationship between a permission set and an application role. When updating `user_role__sys` object records, the `Rolepermissionset` component is updated accordingly.
Conversely, `user_role_sys` object records are updated automatically when `Rolepermissionset` components are created or updated.
Learn more about [role permissions in Vault Help](https://platform.veevavault.help/en/lr/69197), or see the `Rolepermissionset` component in the [Component Type Reference](/mdl/component-reference/component-types/rolepermissionset).
## REST API v21.1 {#rest-api-v211}
### Global Changes {#21r1-global-changes}
### Enhancements to API Limits {#21r1-enhancements-to-api-limits}
As of 21R1, the Vault API no longer enforces daily limits and no longer returns the daily limit HTTP Headers in responses for calls made using v21.1 and higher. The daily limit also no longer appears in **Admin** > **Settings** > **General Settings** and will not be returned in the API Usage log. Previous versions of the API will return static values for the daily limit headers:
* `X-VaultAPI-DailyLimitRemaining: 999,999`
* `X-VaultAPI-DailyLimit: 999,999`
Additionally, the burst limit has been raised to 2,000 calls in a five-minute fixed period. When the burst limit is exceeded, Vault delays all API calls for 500ms and no longer returns an error. Users who exceed the burst limit are logged in the System Audit log and can also be viewed in the API Usage log. Users no longer receive notifications when burst limits are exceeded.
Learn more about [API Limits](/docs/#api_rate_limits).
### New Endpoints {#21r1-new-endpoints}
### Replace Workflow Owner {#21r1-replace-workflow-owner}
This feature introduces the new `replaceworkflowowner` action, which allows Admins to replace the workflow owner of an in-progress object or multi-document workflow using single or bulk APIs. When a workflow owner is replaced, all current and future tasks assigned to the previous owner are reassigned to the new owner.
The `replaceworkflowowner` action is now included in the list of workflow actions returned by the object workflow APIs:
To replace the owner, API requires the new workflow owner ID. The new owner must be able to start the workflow.
To replace workflow owners in bulk, the Bulk API requires the current and new owner IDs and will replace the current owner with the new owner for all workflows.
Learn more in the [v21.1 API Reference](/vault-api/api-reference/21.1/object-lifecycle-workflows/workflows/initiate-workflow-action).
### Object & Multi-Document Workflow: Capacity Without Requiring eSignature {#21r1-object-multidocument-workflow-capacity-without-requiring-esignature}
This feature allows admins to configure capacity in an object or multi-document workflow task without requiring an eSignature. This feature also allows users to set capacity using the Initiate WorkflowTask Action API.
Developers can get capacity details:
Then provide capacity values with key-value pair in body as `capacity__c = {capacity value name}`:
Learn more in the [v21.1 API Reference](/vault-api/api-reference/21.1/object-lifecycle-workflows/workflow-tasks/retrieve-workflow-task-action-details).
### Job API Enhancements {#21r1-job-api-enhancements}
This release, we’ve added several new Vault Job APIs:
* **Retrieve Job Histories**, which retrieves a history of all completed job instances
* **Retrieve Job Monitors**, which retrieves monitors for job instances which have not yet completed
* **Retrieve Job Tasks**, which retrieves a list of tasks for SDK jobs
* **Start Job**, which is analogous to the *Start Now* option in the Vault UI
Learn more in the [v21.1 API Reference](/vault-api/api-reference/21.1/jobs).
### Existing Endpoints {#21r1-existing-endpoints}
### Retrieve Deleted Document IDs API Enhancements {#21r1-retrieve-deleted-document-ids-api-enhancements}
The **Retrieve Deleted Document IDs** response now includes a `deletion_type` property, which denotes how the document or version was deleted:
* `document__sys`: denotes a deleted document
* `document_version__sys`: denotes a deleted document version
* `version_change__sys`: denotes the document version no longer exists as it became a new major version through the *Set new major version* lifecycle entry action
Additionally, the response now includes the Global ID and Global Version ID of the deleted document or version.
Learn more in the [v21.1 API Reference](/vault-api/api-reference/21.1/documents/delete-documents/retrieve-deleted-document-ids).
### Update to Document Token API for Steady State Document Retrieval {#21r1-update-to-document-token-api-for-steady-state-document-retrieval}
This feature enhances the Document Token API with a new `steadyState` body parameter. If this parameter is set to `true`, the API returns the token for that latest steady state version of a document, even if you have access to a newer version. Previous versions will continue to return a “document not found” error.
Learn more in the [v21.1 API Reference](/vault-api/api-reference/21.1/documents/document-tokens).
### Enhance Compare & Configuration Report to Provide Warnings {#21r1-enhance-compare-configuration-report-to-provide-warnings}
This feature enhances the Vault Compare and Configuration Reports to provide a list of potential MDL component and configuration issues in a separate error log for easier troubleshooting.
Learn more in the [v21.1 API Reference](/vault-api/api-reference/21.1/configuration-migration/vault-compare).
### Bulk Object Attachment Delete API Update {#21r1-bulk-object-attachment-delete-api-update}
This feature updates the **Delete Multiple Attachments** API for both documents and Vault objects. Changes include:
* Deleting via the external ID now always requires specifying `idParam`
* Specifying an invalid external id now returns a more accurate error message
* If external ID is specified via `idParam`, the API will always delete via the external ID
Learn more in the [v21.1 API Reference](/vault-api/api-reference/21.1/documents/document-attachments/delete-multiple-document-attachments).
### Document ID included in Audit History CSV {#21r1-document-id-included-in-audit-history-csv}
In previous API versions, retrieving a CSV from the **Retrieve Complete Audit History for a Single Document** endpoint did not include a document ID column. As of API v21.1, the returned CSV now includes a document ID column.
### Audit Trail Export Retrieval Enhancements {#21r1-audit-trail-export-retrieval-enhancements}
As of API v21.1, we've enhanced the Audit Trail APIs to return a programmatically accessible link to the exported CSV in addition to the UI-accessible link. When requesting an audit trail with `format_result = csv`, the job status response will now provide both links.
View the Audit APIs in the [v21.1 API Reference](/vault-api/api-reference/21.1/logs).
### Remove redundant parameters on File Staging API: Create File or Folder {#21r1-remove-redundant-parameters-on-file-staging-api-create-file-or-folder}
The `name` and `size` parameters are no longer required when creating a file or folder. This applies to all versions of the API, but the field and values can be provided for backwards compatibility.
### Application-Specific Endpoints {#21r1-applicationspecific-endpoints}
### Safety Distribution Email Support {#21r1-safety-distribution-email-support}
This feature updates the **Veeva Site Connect: Distribute to Sites** API to support *Study Sites* which are not using Veeva SiteVault. *Study Sites* without active study *Agreements* will receive *Safety Distributions* via a deduplicated daily digest email.
Learn more in the [v21.1 API Reference](/vault-api/api-reference/21.1/vault-query-language-vql).
### Vault Loader {#21r1-vault-loader}
### File Staging for Loader CLI {#21r1-file-staging-for-loader-cli}
With this feature, Vault Loader users with *File Staging* permissions can manage files and folders on Vault’s staging area. Users can view, create, move, rename, delete as well as upload and download to and from the file staging area using the Vault Loader Command Line tool (CLI).
Learn more about the [Vault Loader File Staging CLI in Vault Help](https://platform.veevavault.help/en/lr/67334).
## VQL {#vql}
### VQL on Documents with Roles {#21r1-vql-on-documents-with-roles}
This feature allows developers to query document roles and retrieve fields and filter by related documents, users, and groups. For example, developers can query for document owners in a specified group, or retrieve the current editors for a filtered set of documents.
Learn more about [querying document roles](/vql/query-targets/document-roles).
### Enable VQL Alias Support for Object Queries {#21r1-enable-vql-alias-support-for-object-queries}
The `AS` Clause is now supported on object queries when used with the `LONGTEXT()` and `RICHTEXT()` functions. These methods can only be used on Long Text and Rich Text fields, and aliased field names must be unique.
Learn more about [aliases](/vql/clauses/as).
### Related Document Section Filters {#21r1-related-document-section-filters}
This feature adds the ability to specify criteria VQL filters to related document sections on object page layouts. In MDL for `Pagelayout` components, these filters are reflected in the xml value of the `page_markup` attribute.
## MDL {#mdl}
### Quality Teams: Team Role Restrictions & Enhancements {#21r1-quality-teams-team-role-restrictions-enhancements}
To support enhancements to Team Roles, this feature adds the `exclusive_membership` attribute to the `Qualityteamrole` subcomponent type. For specific team roles within the team, if `exclusive_membership` is `true` on a given team-enabled record, users in this role cannot be assigned to any other team role. If omitted, the default value is `false`.
Learn more about the `Qualityteamrole` subcomponent in the [Component Type Reference](/mdl/component-reference/component-types/qualityteamrole).
### Web Sections for Object Page Layouts {#21r1-web-sections-for-object-page-layouts}
With this release, Admins can add external web content into object page layouts using *Web Sections*, which are similar to *Web* tabs. You can specify the URL of external web content, and a set of dynamic tokens are available for usage. For example, you can configure *Web Sections* to display an address’s map location on an *Organization* record.
You can only add *Web Sections* through MDL by editing the `page_markup` attribute of the `Pagelayout` component.
Learn more about [Web Sections](/mdl/documentation/guides/creating-web-sections).
### Tags Supported in Report MDL {#21r1-tags-supported-in-report-mdl}
This feature adds the `tags` attribute to the report component. Tags may now be defined in sandbox Vaults and migrated to production.
See the Report component in the [Component Type Reference](/mdl/component-reference/component-types/report).
## Vault Java SDK {#vault-java-sdk}
### General {#21r1-general}
### Record UI Action Enhancements (Notification + Action Dialog) {#21r1-record-ui-action-enhancements-notification-action-dialog}
An optional dialog can be shown in the UI before action execution for a class that implements the `RecordAction` interface. `onPreExecute` allows a confirmation dialog to be displayed to the user prior to the execution of a record action. A custom dialog title and message can be added.
Notification Banners can be shown in the UI after action execution. `onPostExecute` allows a post record action execution banner to be displayed to the user. A custom banner message can be added.
Learn more about [pre-action and post-action UI behavior](/vault-sdk/entry-points/actions/record-actions).
### SDK Job Queues {#21r1-sdk-job-queues}
Developers can now create custom SDK job queues which can be referenced from the *Queue* field for any custom SDK job metadata component. Prior to this release, it was not possible to create custom job queues and only *System* queues were available. If a queue is not specified, the *System* queue is used by default.
Additionally, Spark and Job queues are managed independently from each other and are controlled with separate permissions. Instead of one *Queues* permission, the queues are now controlled by the *Spark Queues* and *SDK Job Queues* permissions, respectively. Users who previously had the Queues permission will automatically have both the *Spark Queues* and *SDK Job Queues* permissions.
Any MDL or VPKs generated prior to this change which include permission sets must be regenerated to accurately reflect permissions.
### Notification Template SDK {#21r1-notification-template-sdk}
Developers can now use the Notification Token Resolver to more efficiently resolve token values, particularly if there are a large number of tokens to be resolved.
### Deprecate VaultRuntimeException {#21r1-deprecate-vaultruntimeexception}
In this release, we’ve deprecated `VaultRunTimeException` from the Vault Java SDK. This exception could not be swallowed or altered, and should have no impact on existing implementations.
### Vault Java SDK Service Account {#21r1-vault-java-sdk-service-account}
A new Java SDK Service Account user appears in the **Users & Groups** tab. This system-managed, read-only user will support future Vault functionality. Vault does not include this user in license counts.
### Spark Messaging {#21r1-spark-messaging}
### Move Spark Queues to the Connection Tab {#21r1-move-spark-queues-to-the-connection-tab}
Administrators can now access Spark queues in one place under the **Connections** tab alongside the other Spark componentry. This enhancement streamlines UI navigation when creating Spark integrations.
### Query Object Rules Filter Clause Enhancements {#21r1-query-object-rules-filter-clause-enhancements}
In this release, we’ve modified the Criteria VQL available for a query object’s Filter Clause. Starting with this release, filter clauses only support the `WHERE` clause. All other VQL clauses are no longer supported, including:
* `ORDER BY`
* `PAGESIZE`
* `PAGEOFFSET`
Additionally, you no longer need to enter the keyword `WHERE` in your filter clause. For example, in previous releases you’d enter your filter clause as` WHERE status__v = 'active__v'`, but now you must only enter `status__v = 'active__v'`.
Any existing filter clauses which still have `WHERE`, `ORDER BY`, `PAGESIZE`, or `PAGEOFFSET` in them after this release must have these keywords removed for the integration to continue to work. We encourage users to make the appropriate changes as soon as 21R1 is released.
Learn more about [Criteria VQL for filter clauses](https://developer.veevavault.com/vql/#Filter_Clause).
### Spark Integration Rule Support for Object Relationships {#21r1-spark-integration-rule-support-for-object-relationships}
Spark integration rules which fetch and map data in Vault to Vault integrations now support object relationship from the source Vault. This allows field rules to natively support subqueries in the VQL call-back.
For example, there is a Spark integration which needs to retrieve a *Product’s Manufacturer’s Incident Phone Number*, where *Manufacturer* is represented as an object relationship field on the *Product* object. With this feature, integration rules have access to the relationship between *Product* and *Manufacturer*.
For example, there is a Spark messaging integration which needs to retrieve the *Manufacturer’s Phone Number* for a given *Product*, where *Manufacturer* is represented as an object relationship field on the *Product* object. With this feature, integration rules can map the relationship between Product and Manufacturer. For example, *Vaccine* is a *Product* object record that has a *Manufacturer* field with the value *VeePharm*, where *VeePharm* is a *Manufacturer* object record which has a text field labelled *Phone Number*. Given the *Vaccine* product, this Spark messaging integration can quickly grab the *Phone Number* on the related *VeePharm* manufacturer.
### Enable User Exception Record Save on Message Processor Failure {#21r1-enable-user-exception-record-save-on-message-processor-failure}
Developers writing Spark message processor code for Spark-based integrations can now surface a User Exception without it being rolled back when a `RollbackException` is thrown. Using the `getErrorProvider().setError()` method on the message context, developers can configure creation of a single User Exception record when an unrecoverable error occurs.
### Inactivate Standard Integration Rules & Edit Field Defaults on Standard Field Rules {#21r1-inactivate-standard-integration-rules-edit-field-defaults-on-standard-field-rules}
Standard integration rules can now be delivered as inactive, allowing Admins to turn them on or off as needed. Additionally, you can now edit field defaults for Standard field rules.