Navata
← All Library

Veeva Vault Architecture

How to Govern Veeva Vault Java SDK Custom Code in a GxP System

AI-assisted research and drafting · Practitioner reviewed by Rohith Karanam Sreedhar · 15 September 2026

ⓘ Library content is researched and drafted with AI assistance and reviewed by a Navata practitioner before publication. For original analysis and long-form practitioner perspectives, visit Navata Insights →

Vault Java SDK code is not merely documentation beside configuration. Veeva describes the SDK as a way to extend Vault with custom triggers, actions and services. Uploaded source code is stored as metadata, can be moved from sandbox to production and, once deployed, is compiled and loaded so the custom logic can take effect. That makes custom code a design element whose control should match the consequence of what it can do.

Put the code inside the process boundary when its effect is consequential

Start from the business effect, not the technology label. A trigger that formats a noncritical display value is different from code that changes a deviation state, creates a regulated record, alters a calculated field, selects a route, calls an external service or controls whether an action is available.

For each extension, state:

  • the event or user action that invokes it;
  • the records, fields and lifecycle states it may read or change;
  • the initiating user or process context and the business authority that should govern the action;
  • the expected output and allowed side effects;
  • the failure behaviour, including whether the transaction stops, rolls back or leaves follow-up work;
  • the records or logs that allow an operator to reconstruct what occurred.

That statement becomes the assurance boundary. It is more useful than a generic declaration that the SDK is "validated."

Treat platform privilege as a design risk

Veeva documents that custom SDK code executes through the Java SDK Service Account with Vault Owner-level access. It also states that normal user, record and field access restrictions do not apply to object access performed by the custom code, and that developers are responsible for considering the initiating-user context and applying controls where appropriate.

That is a platform execution condition, not a recommended authorisation model for a regulated process.

Do not let the broad technical authority of the SDK service account silently become the business authority of the workflow. Where the process requires the initiating user's role, record access, lifecycle authority or another business rule to constrain the outcome, enforce that boundary deliberately in the design and test it.

Useful negative tests include:

  • a user who may view a record but must not invoke the consequential change;
  • a user who may invoke the action on one population but not another;
  • a lifecycle state in which the code must refuse to act;
  • a field or object that the code must not modify even though the platform identity technically could;
  • an indirect trigger path where the initiating user is different from the technical identity shown in execution.

Audit attribution is still important. Veeva records SDK activity as the Java SDK Service Account acting on behalf of the initiating user in relevant audit entries. That helps reconstruct who initiated the event, but attribution does not replace an authorisation decision.

Build evidence around the exact version promoted

Keep the source version, review record and deployment package tied together. Code review should focus on the consequential paths: data writes, lifecycle transitions, queries, external calls, exception handling, retry behaviour and any operation that depends on the privileged SDK execution context.

Testing should cover representative normal cases and deliberately selected failures. Useful negative cases include missing data, unexpected record states, unavailable dependencies, duplicate invocation, insufficient business authority, timeout and exception paths. Confirm not only the user-visible result but also the stored record state and audit evidence.

Veeva supports deployment through configuration migration packages. Use that capability to bind the reviewed code and dependent configuration into a controlled promotion unit. Review the package contents before deployment, then verify the target Vault contains the intended extension and dependency state. If any component activates immediately, plan the deployment window and verification accordingly.

Do not stop at a successful deployment

After production promotion, retain an inspectable record of the deployed version, package, deployment result, verification and any known limitations. Define who watches runtime and debug information, what constitutes an operational incident and how repeated failures are escalated.

Monitoring should be linked to the business consequence. A runtime error that prevents a cosmetic enrichment is not equivalent to an error that blocks an investigation transition or creates an incomplete regulated record. The owner should know which failures require record-level reconciliation rather than only technical correction.

Reopen assurance when the relied-upon conditions change

Reassess when custom code, its dependent fields or objects, invoked actions, service-account behaviour, external endpoints, platform limits or the regulated process changes. A code file can be unchanged while its effect changes because the surrounding configuration or data model changed.

EU GMP Annex 11 requires controlled change and configuration management for computerised systems used in GMP. It does not prescribe a Java SDK lifecycle. The control method here is practitioner guidance for applying that lifecycle expectation to a Vault-specific extension.

Important boundaries

This article does not say that every Java SDK line requires the same validation formality. The evidence should be proportionate to intended use, risk and consequence. Nor does Veeva's ability to compile and deploy code establish customer acceptance of a regulated use.

The platform's Vault Owner-level SDK execution context should not be read as permission to design broad business authority. Where the platform gives code more technical access than the initiating user or process should have, that difference is itself part of the control design.

Sources