Managing Vault Java SDK Solutions

The Vault Java SDK is a powerful tool which allows developers to extend Vault and deliver custom capabilities. Learn more about the Vault Java SDK in the Developer Portal.

Note: Veeva is upgrading the Vault Java SDK to Java 17 to allow developers to take advantage of the features and upgrades that come with the new version. To prepare your custom solutions for the Java 17 upgrade, test your code now by enabling Java 17 from Admin > Settings > General Settings and selecting Use Java 17 Compilation and Runtime. Learn more about this change on the Developer Portal.

You can manage the Vault Java SDK solutions from Admin > Configuration > VAULT JAVA SDK.

Each solution shares the following common properties:

Name: This ID is how developers refer to the solution in custom code. This name never appears in the Vault UI.
Label: The UI label for the solution. For example, the label for a document action is what appears for users in the Actions menu for a document, and the label for a record workflow action is what appears for Admins when configuring a workflow. Some solutions, such as triggers, do not appear in the UI and do not have a label.
Source: The origin of the Vault Java SDK solution. For example, Custom means this solution was developed for your organization. Vault Admins can interact with Custom solutions and may be able to enable or disable the solution, download the source code, or otherwise edit solution properties. System solutions are developed by Vault and work to deliver various Vault features. Standard solutions are also developed by Vault and work to deliver various features specific to your application. Vault Admins cannot interact with System or Standard solutions.
Operational Status: The on-off status of your solution. For example, only Active actions appear in the UI for execution, only Active triggers execute on events, and only Enabled classes are available for use.

Document Actions

This page shows various information about document actions deployed to your Vault. To download a Custom document action’s source code or enable/disable a Custom action, use the Actions menu in the Name column.

Lifecycle: The lifecycle where this document action is available.
Usage: Specifies where in Vault this action is available for configuration and execution. For example, User Action or Entry Action. UNSPECIFIED means the action is available everywhere document actions are supported.

Record Actions

This page shows various information about record actions deployed to your Vault. To download a Custom record action’s source code or enable/disable the Custom action, use the Actions menu in the Name column.

Lifecycle: The lifecycle where this record action is available.
Type: The type of record action, for example, Object.
Object: The object this record action is associated to, for example, product__v.
Usage: Specifies where in Vault this action is available for configuration and execution. For example, User Action. UNSPECIFIED means the action is available everywhere record actions are supported.

Record Workflow Actions

This page shows various information about record workflow actions deployed to your Vault. To download a Custom record action’s source code or enable/disable the Custom action, use the Actions menu in the Name column.

Object: The object this record workflow action is associated to, for example, product__v.
Step Types: The step types where this record workflow action is allowed to execute, for example, TASK.

Record Triggers

Record triggers execute custom code when a record Event occurs. This page shows various information about the record triggers currently deployed to your Vault.

Hovering over a Custom record trigger will reveal an Actions menu in the Name column to download the trigger source code or enable/disable the trigger.

Object: The object this record trigger is associated to, for example, product__v.
Events: The Events specifying when this record trigger executes. For example, BEFORE_UPDATE means the trigger executes right before the record updates.
Order: If multiple triggers exist on the same object, this specifies the order this record trigger will execute. Order 1 executes first and Order 10 executes last. UNSPECIFIED means this trigger will always execute last.

Record Role Triggers

Record role triggers execute whenever roles are manually added or removed from an object record. This page shows various information about the record role triggers currently deployed to your Vault.

Hovering over a Custom record trigger will reveal an Actions menu in the Name column to download the trigger source code or enable/disable the trigger.

Object: The object this record role trigger is associated to, for example, product__v.
Events: The Events specifying when this record role trigger executes. For example, BEFORE means the trigger executes right before the record role assignment.
Order: If multiple triggers exist on the same object, this specifies the order this record role trigger will execute. Order 1 executes first and Order 10 executes last. UNSPECIFIED means this trigger will always execute last.

User-Defined Classes

User-defined classes (UDCs) allow you to put reusable logic in a class. For example, you can implement logic in a single UDC rather than repeating the same logic across multiple triggers on different objects. Unlike triggers and actions, which execute when a user or the System initiates an operation, UDCs only execute by calls from other classes.

To download Custom UDC source code, use the Actions menu in the Name column.

User-Defined Models

User-defined models (UDM) allow you to create reusable data access objects, or models, and annotate their getters and setters as user-defined properties. You can then use models with JsonService to translate data to and from JSON, or with HttpService to send and receive data using REST APIs.

To download Custom UDM source code, use the Actions menu in the Name column.

Include: The serialization behavior of the UDM.
Parent: If this UDM extends another UDM, this column displays the Name of the parent model.

User-Defined Services

User-defined services (UDS) allow you to wrap reusable logic into a service that can be used by other Vault Java SDK code, such as triggers, actions, or user-defined classes. UDS only execute by calls from other classes, differentiating them from Vault extensions that execute when a user or the system initiates an operation. Additionally, UDS helps developers with memory management by deallocating local memory when method execution has ended.

To download UDS source code, use the Actions menu in the Name column.

The Interface column displays the name of the interface implementing this user-defined service.

Job Processors

Job processors provide logic to process jobs in bulk. You can invoke a job processor through any custom Vault Java SDK code. For example, you can create a trigger or action which executes the job processor under certain conditions.

You can also use a job processor as logic for a new job definition. For example, you can create a custom job definition available to Vault Admins to execute your custom code at scheduled or recurring intervals.

Email Processors

Email processors take data from emails and convert it into document, object record, or attachment field values and content. For example, the Create Document from Email processor turns an email into a document and stores attachments as document attachments.

Learn more about Email Processors.

Web APIs

Developers can create custom API endpoints, called Web APIs, which are visible in the Vault Admin UI from Admin > Configuration > Vault Java SDK > Web API.

Each Web API must be assigned to a Web API Group, which determines the permission sets users must be assigned in order to use APIs in this group. Admins can manage Web API Groups from Admin > Configuration > Business Logic > Web API Groups.

Message Catalog

The Message Catalog enables you to view, manage, and create Message Groups for use with Vault Java SDK extensions. Click into a group to modify details or add a Message.

Learn more about Using the Message Catalog.

Record Merge Event Handlers

Record merge event handlers contain custom logic to execute as a merge starts or after the merge finishes. This allows organizations to customize merge behavior. For example, directly after a merge starts, you can retrieve the field values on the Duplicate record. Directly after the merge completes, you can update any desired information from the Duplicate record to the Main record. This overrides the default merge behavior which does not copy data between the duplicate and Main record.

Record merges only occur if your organization creates a custom API or SDK integration which invokes a record merge. Record merges cannot be initiated in the UI. Learn more about merging records.

This page shows various information about the record merge event handlers deployed to your Vault.

Object: The object for which the record merge event handler will execute. For example, a handler on the product__v object will only execute when product__v object records are merged. Each object can have one (1) record merge event handler.