Java SDK Service Account

Similar to the System and Application Owner users, the Java SDK Service Account user appears in your Vault to run Vault Java SDK code. This user is not included in license counts.

Note

By default, all Vault Java SDK code executes as the Java SDK Service Account, except for custom Web APIs which execute as the Request_Owner by default.

The Java SDK Service Account has Vault Owner-level access. Vault entry points, such as triggers and actions, can access object records with full read/write permission. This means any Vault user-level, record-level, or field-level access restrictions do not apply. Custom code can copy or move data from object to object and delete data without regards to who the user is. It is the developer's responsibility to take that current user context into consideration and apply control where appropriate.

Data security should be considered when designing solutions using the Vault Java SDK.

Tip

To configure a field to allow changes from custom code only, Admins can use Atomic Security to hide a field from all business users, in which case custom code can still access this field because of Vault-Owner level access. Learn about Atomic Security for objects and Atomic security for Documents in Vault Help.

Because the Java SDK Service Account has Vault Owner-level access, SDK code cannot directly edit fields that a Vault Owner could not edit.

For example, the following component fields on documents cannot be directly edited by a Vault Owner or with Vault Java SDK:

• major_version__v and minor_version__v: Instead of editing these fields directly, these fields only change during a document versioning event.
• status__v: Instead of editing this field directly, you must move the document through its document lifecycle. Vault Java SDK does not support Document Migration Mode.
• type__v, subtype__v, classification__v, lifecycle__v: Instead of editing these fields directly, you must reclassify the document.

Learn more about the Vault Owner security profile in Vault Help.