# 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.
You can manage the Vault Java SDK solutions from **Admin > Configuration** in the _VAULT JAVA SDK_ section. 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. ## Web APIs {#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**. ## Document Actions {#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. ## Doctype Triggers {#document-type-triggers} Doctype triggers execute custom code when a document or document version Event occurs. This page shows various information about the doctype triggers currently deployed to your Vault. Hover over a doctype trigger's _Name_ column to display an **Actions** menu with actions to enable or disable the trigger and download the trigger source code. The following default columns are displayed on the _Document Type Triggers_ page: * **Document Type**: The document type the trigger is associated with, for example, `base_document__v`. * **Events**: The Events specifying when the doctype trigger executes. For example, _AFTER\_INSERT_ means the trigger executes right after the document or document version is created. * **Order**: If multiple triggers exist on the same document type, this specifies the order in which this trigger is executed. _Order 1_ executes first and _Order 10_ executes last. _UNSPECIFIED_ means this trigger always executes last. * **Level**: The levels, _Document_ or _Document Version_, at which the doctype trigger executes. * **Source**: The source of the doctype trigger. _Custom_ is the only source displayed in this column. * **Operational Status**: Whether the doctype trigger is _Enabled_ or _Disabled_. * **Created By**: The username of the user who created the doctype trigger. * **Created Date**: The creation date and time of the doctype trigger. * **Last Modified By**: The username of the user who last modified the doctype trigger. * **Last Modified Date**: The last modified date and time of the doctype trigger. ## Email Processors {#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](/en/lr/74665/). ## Job Processors {#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](/en/lr/22897/#Define_SDK_Jobs). For example, you can create a custom job definition available to Vault Admins to execute your custom code at scheduled or recurring intervals. ## Message Catalog {#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](/en/lr/58076/). ## Record Actions {#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 Merge Event Handlers {#record_merge} 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 Vault API or SDK integration which invokes a record merge. Record merges cannot be initiated in the UI. Learn more about [merging records](/en/lr/659058/). 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. ## Record Role Triggers {#record_role_trigger} 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. Hover over a _Custom_ record role trigger's _Name_ column to display an **Actions** menu with actions to enable or disable the trigger and download the trigger source code. The following columns are displayed on the _Record Role Triggers_ page: * **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 always executes last. ## Record Triggers {#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. Hover over a _Custom_ record trigger's _Name_ column to display an **Actions** menu with actions to enable or disable the trigger and download the trigger source code. The following columns are displayed on the _Record Triggers_ page: * **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 always executes last. ## Record Workflow Actions {#record_wf_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_. ## User-Defined Classes {#user_defined_class} 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_model} 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_service} 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][4]. 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. [4]: #user_defined_class