Vault Developer Release Notes
Filters
Application Family
Tags
We are pleased to bring you the following additions and enhancements to Developer Portal features in 23R3.
Developer Features in 23R3
Section link for Developer Features in 23R3We are pleased to bring you the following additions and enhancements to Developer Portal features in 23R3. REST API features added in 23R3 only affect API v23.3, unless otherwise noted.
Service Announcements
Section link for Service AnnouncementsEnd of Support for REST API v6.0 and below
Section link for End of Support for REST API v6.0 and belowWith 23R2.4, API versions 6.0 and below will no longer be supported. These versions will no longer be tested and the Retrieve API Versions endpoint will no longer return v6.0 and below. There are no active custom integrations using these older versions, and there is no action needed by Vault Admins.
REST API v23.3
Section link for REST API v23.3Existing Endpoints
Section link for Existing EndpointsObject Records API: Max Input Size Update
Section link for Object Records API: Max Input Size UpdateIn API v23.3, we have raised the limit for maximum input size from 10 MB to 50 MB when using the Create Object Records and Update Object Records endpoints. Previously, this limit was incorrectly documented as 1 GB.
/api/{version}/vobjects/{object_name}/api/{version}/vobjects/{object_name}We also enhanced our maximum input size calculation so that it checks against the actual file size prior to deserialization. This change makes it easier and much more predictable for developers to avoid going over the limit.
EDL: Document Matching for Inactive Records
Section link for EDL: Document Matching for Inactive RecordsTo maintain data integrity and consistency with Vault UI, Vault API no longer supports including inactive EDL Item records or EDL Item records with an inactive parent EDL record when adding or removing EDL Matched Documents. Developers should check record status before calling Vault API. This change only applies to API v23.3+.
Intelligent Document Update
Section link for Intelligent Document UpdateVault will now only update document metadata if any changes have been made. Prior to this release, if a record was saved without any changes being made, it would count as an update. As a result, all document update related transactions would occur, such as updating the Last Modified Date and creating an audit trail entry. In 23R1.2, these transactions will no longer occur for no-change saves.
With API v23.3 or later, if an API call to upsert or update documents results in no changes, the API response will include a warning of either No changes in values - document not updated (for single records) or No changes in values - one or more documents not updated (for multiple documents). In this case, the record’s Last Modified Date is not changed (v23.2 or later), and Vault does not create an event in the Document Audit History (all versions).
Additional Sandbox Sizes in Vault
Section link for Additional Sandbox Sizes in VaultWe are further adjusting sandbox sizes as shown in the table below. These changes are in response to working with and listening to customers as they refine their environment management process.
| Sandbox Size | Use | Object Record Support | Document Version Support | Snapshots | Included |
|---|---|---|---|---|---|
| Small | Personal Dev/Test | 0 - 100 K | 0 - 10 K | 2 snapshots | 4 |
| Medium | Shared Dev, Test, UAT | 100 K - 1 M | 10 K - 100 K | 2 snapshots | 2 |
| Large | Migration Testing | 1 M - 10 M | 100 K - 1 M | 2 snapshots, Limited size* | 0 |
| Very Large | Migration Testing | 10 M - 100 M | 1 M - 10 M | 2 snapshots, Limited size* | 0 |
| Extra Large | Migration Testing | 100 M - 500 M | 10 M - 50 M | 2 snapshots, Limited size* | 0 |
| Full | Migration Testing | No Limit | No Limit | 2 snapshots, Limited size* | 1 |
*Snapshots on Large, Very Large, Extra Large, and Full sandboxes are limited to 10 million records, 100,000 document versions, and 50 GB of source content.
With API v23.3, the Retrieve Sandboxes endpoint will now return new size values for "Medium", "Very Large", and "Extra Large" sandbox sizes.
{
"responseStatus": "SUCCESS",
"data": {
"entitlements": [
{
"size": "Extra Large",
"available": 1,
"allowed": 2,
"temporary": 0
}
]
}
}EDL: Atomic Security for EDL Item Actions
Section link for EDL: Atomic Security for EDL Item ActionsIn 23R2.3, Admins will now have the ability to leverage Atomic Security on EDL Item Actions and Controls. With this change, The following endpoints will require that the executing user has the appropriate permissions through Atomic Security, in addition to their Security Profile:
/api/{version}/objects/edl_matched_documents/batch/actions/add/api/{version}/objects/edl_matched_documents/batch/actions/remove/api/{version}/vobjects/edl_item__v/actions/createplaceholderSkip Object Lifecycle Event Actions in Record Migration Mode
Section link for Skip Object Lifecycle Event Actions in Record Migration ModeWith v23.3, Vault now skips Create Record object lifecycle event actions when objects are created via the Create Object Records API with the X-VaultAPI-MigrationMode header enabled. Create Record event actions will continue to execute in API v23.2 and below.
/api/{version}/vobjects/{object_name}When migrating data, event actions are generally not applicable, and any required data should be included in the migration process. Skipping these via Record Migration Mode provides a consistent data migration process that matches Document Migration Mode.
Enhanced Document Role Assignment
Section link for Enhanced Document Role AssignmentWith v23.3, the following endpoint now supports the removal of users from document roles that are controlled by Dynamic Access Control (DAC):
/api/{version}/objects/documents/{doc_id}/roles/{role_name_and_user_or_group}/{id}Previously, users could be manually added to a role that is controlled by DAC, but Vault would prevent the removal of those manual assignments. With this enhancement, we are simplifying this and making the behavior consistent.
Workflow Due Date
Section link for Workflow Due DateWorkflow date prompts in the start step can now be set as the workflow due date, enabling the workflow to track its own due date in addition to task due dates. This gives workflow owners better visibility into the timelines for active workflows. Task due dates that are configured with the workflow due date as their date can be updated in a single action from the Active Workflow actions and from the Retrieve and Initiate Workflow Action REST APIs, and Workflow Action Java SDK.
This feature is not applicable to legacy workflows.
Send as Link Version Binding
Section link for Send as Link Version BindingWhen querying document roles in VQL, developers may see a role of External Viewer. This is a system-managed role, with no assigned permissions, granted to non-Vault recipients via Send as Link. It is not available as a query target.
Learn more about Send as Link in Vault Help
Display Format: Email Link
Section link for Display Format: Email LinkThe 23R2 release introduced the ability for Admins to configure how text and number field values should be displayed in Vault using format masks. To support format masks in API v23.2, Query Describe in VQL includes a format_mask attribute for text and number fields. A new VQL function, TODISPLAYFORMAT(), returns the formatted value of text fields, number fields, formula fields (where the return type is Text or Number), and lookup fields (that are looking up text or number field values). With 23R3, Admins can now use the Display Format functionality to configure format masks on text fields to wrap any entered text as “mailto” hyperlinks using a new EmailFormat() function. In API v23.3, when querying fields are configured to use the EmailFormat() function, and the TODISPLAYFORMAT() function is leveraged, the returned values will be in the email format.
SELECT id, email__sys, TODISPLAYFORMAT(email__sys) AS email_formatted
FROM person__sys{
"responseStatus": "SUCCESS",
"responseDetails": {
"pagesize": 1000,
"pageoffset": 0,
"size": 1,
"total": 1
},
"data": [
{
"id": "V0D000000001001",
"email__sys": "olive@veepharm.com",
"email_formatted": "<a href=\"mailto:olive@veepharm.com\">olive@veepharm.com</a>"
}
]
}This function is not supported in WHERE clauses. By default, queries that do not use this function return the raw field value. Learn more about TODISPLAYFORMAT().
The Vault Java SDK returns the raw field value.
Learn more about format masks in Vault Help
FAVORITES and RECENT for Objects
Section link for FAVORITES and RECENT for ObjectsVQL now supports additional query target options, FAVORITES and RECENT. These will allow developers to execute VQL queries on objects using the Vault REST API and filter the results to object records that have been marked as favorite (FAVORITES) or most recently viewed object records (RECENT).
Support for VQL queries on favorite and recent documents was added in a prior release; this extends the capability to allow developers to perform similar queries on objects.
Vault Java SDK
Section link for Vault Java SDKEvaluate Field Rules: Reference Lookups & Default Values
Section link for Evaluate Field Rules: Reference Lookups & Default ValuesWhen evaluating field rules using IntegrationRuleService#evaluateFieldRules, if the field rule configures a reference lookup and a default value, Vault now returns the default value instead of an error when there is no match in the reference lookup.
This applies when:
- The field rule is for an integration rule with documents as the primary query object
- The query object is a relationship to a related object (
__vror__cr; meaning the query result data is a subquery) - The field rule has both a reference lookup and a field default
- The related object’s query field is not populated
This enhancement helps reduce unnecessary errors and user exception messages in Vault connections.
We encourage developers to review their code and configuration to ensure their field rules are evaluated properly.
Annotation Service: Create, Edit, Delete
Section link for Annotation Service: Create, Edit, DeleteAnnotationService has been enhanced to allow developers to create, edit, and delete document annotations using Vault Java SDK. Previously, only read access was available. This improvement allows developers to solve complex business requirements and build automation for annotations.
Learn more about Annotation Service.
Object Attachments for SDK
Section link for Object Attachments for SDKDevelopers can now create, update, and delete object record attachments using the Vault Java SDK. Within any SDK entry-point, developers can create attachments from existing document content, document attachments, or document renditions. Inside email processors, developers can create attachments from email content and email attachments.
Record Display Service
Section link for Record Display ServiceA new SDK service, RecordDisplayService, allows developers to format object record values as display values. This enables user-facing object record values to be generated for message prompts and notifications.
Learn more about RecordDisplayService in the Javadocs
Object References in Field Rules
Section link for Object References in Field RulesField Rules can now be configured with a Target Field Lookup (target_field_lookup) that allows admins to configure object reference lookups to be used when evaluating field rules. For example, Admins can configure a field rule for a child object that uses parent__cr.name__v for an object reference instead of using IDs. This eliminates the need to maintain reference lookup values, and instead developers can code their integrations to dynamically resolve object references.
Email to Vault SDK: Inbound Email Address in EmailProcessorContext
Section link for Email to Vault SDK: Inbound Email Address in EmailProcessorContextWith v23.2.3, the EmailProcessorContextgetInboundEmailAddress(). This method allows developers to access the name of the inbound email address component in custom SDK code.
Learn more about Email Processors.
Object Type Metadata Service
Section link for Object Type Metadata ServiceDevelopers can now access object type and object type field metadata with the Vault Java SDK. This allows custom SDK code developers to write object type specific logic without using VQL or REST API to retrieve object type metadata.
This feature adds several new interfaces in the data package as well as the following new methods in ObjectMetadataService:
getObjectTypes()getObjectTypeFields()newObjectTypeMetadataCollectionRequestBuilder()newObjectTypeFieldMetadataCollectionRequestBuilder()
These new methods and interfaces mirror those already available for object and object field metadata.
Workflow & Lifecycle SDK Updates
Section link for Workflow & Lifecycle SDK UpdatesThe Vault Java SDK now supports execution of active workflow actions. You can view the available actions in the new WorkflowAction Enum, which include:
ADD_PARTICIPANTS: Adds participants to an active workflow.CANCEL_WORKFLOW: Cancels an active workflow.REMOVE_ITEMS: Removes documents or records from an active workflow.REPLACE_WORKFLOW_OWNER: Replaces the workflow owner of an active workflow.
In addition, ObjectLifecycleStateUserActionService now supports execution of start workflow lifecycle user actions.
Language & Region for VaultInformationService
Section link for Language & Region for VaultInformationServiceVaultInformation now supports retrieving the following Language & Region Settings from Vault:
- Base Language
- Base Locale
- Vault Time Zone
Configuration Data Attribute for Objects
Section link for Configuration Data Attribute for ObjectsDevelopers will now have the ability to confirm which objects will have object records copied when generating a sandbox Vault. If configuration_data is true, object records of this type will be copied. If false, they will not. This attribute is read-only.
Document Reference: Latest Steady State Version
Section link for Document Reference: Latest Steady State VersionWhen configuring Document Reference fields on Objects, Admins will have a new version binding option called Latest Steady State Version. To support this functionality, Object field MDL now supports a third value option, latest_steady_state_version, for the document_version_reference attribute. This option behaves similarly to the latest option, except that it will only update its reference if the new version is in a steady state.
Prevent Custom Triggers
Section link for Prevent Custom TriggersDevelopers will now see a new attribute called triggers_allowed, which allows them to see whether or not custom triggers are allowed on a given object. This attribute is read-only.
Workflow Segregation of Duties
Section link for Workflow Segregation of DutiesWorkflows now provide the option to enforce policies that preclude certain users from completing tasks in the workflow based on their role membership or their task completion history in the same workflow. This can help mitigate non-compliance issues during one or two stage approval workflows on GxP content. To facilitate this, the Objectworkflow component type now has two new attributes that specify if these policies are enabled:
users_can_only_complete_one_task: The policy to preclude users in the workflow from completing more than one task in the current workflowroles_cannot_complete_task: The policy to preclude all users in the specified role from completing any task in the workflow