Ask a clinical systems team what they test and you will get a list of modules: CTMS, eTMF, Study Startup, Payments, CDMS. Ask them what they actually test and you will get a much shorter and more honest answer, which is usually "the last study we stood up, by hand, once."
The reason is not laziness, it is arithmetic. Veeva Vault Clinical is not one application. It is one platform hosting as many applications as you have active studies, because a study is a configuration: its own casebook, its own TMF milestone template, its own monitoring visit plan, its own country and site list, its own SDV rules, its own protocol amendments arriving on their own schedule. Vault then ships three general releases a year underneath every one of those configurations at once. 26R1 went general in April 2026, 26R2 in August 2026, and 26R3 is already booked.
Multiply it out and you get the shape of the problem. Nobody can regression-test every study against every release by hand, so nobody does, so the coverage decision is made by whoever happened to be free that week. This post is about making that decision deliberately: what to test in Vault Clinical, what to explicitly not test, and how to build the suite so that adding study number fourteen does not cost you a fourteenth suite. It assumes the auth-bridge and data-seeding groundwork from the Vault CRM testing recipe, which is the same in every Vault application and is not repeated here.
The multiplication nobody puts on a slide
Two responses to this matrix are common and both are wrong. The first is to test one representative study and assume the rest behave identically, which is exactly the assumption that per-study configuration exists to violate. The second is to attempt full coverage per study, which collapses under its own weight before study four and leaves the team believing automation does not work here.
The workable third answer is to split the surface into two categories and treat them completely differently.
- Platform invariants. Behavior that is identical regardless of study configuration: navigation, document upload and classification, the milestone engine, workflow state transitions, permissions and blinding enforcement, the connection handoffs. This is where release regressions actually land, because this is the code Veeva ships. Test it deeply, once, against a reference study.
- Study configuration. Casebook layouts, visit schedules, TMF expectation sets, country requirements. This is where your mistakes land, and it changes on your schedule, not Veeva's. Test it shallowly, per study, at study startup, with a small standard checklist rather than a bespoke suite.
Two suites, two cadences. The platform suite runs against every Limited Release sandbox and gates the release. The study checklist runs once when a study is configured and again after each protocol amendment. Nobody has to test everything against everything, which is the only version of this that survives contact with a real clinical operations calendar.
The connection boundary is where clinical data actually breaks
If you have budget for exactly one thing, spend it here. The most damaging failures in a clinical stack are not inside a module, they are at the seams between modules, and Veeva has been adding seams steadily. The 26R1 release brought new Connections across the suite, including Clinical Operations to EDC, Quality to RIM, and RIM to Medical.
The Clinical Operations to EDC connection is a good worked example of why seams are dangerous. Before 26R1, Vault CTMS represented a subject visit's data status coarsely: complete, or not started. 26R1 made that link substantially more granular, carrying source data verification and data management review detail across. That is a real improvement for monitors. It is also a schema and rendering change to a value that drives monitoring visit planning, and it arrived in a release.
Testing a seam has an awkward property: neither side owns the failure, so neither side's tests catch it. The pattern that works is to make the assertion at the point of consumption, in the rendered destination view, against a baseline captured when the crossing was known good. Seed a subject with a known data state in the source system, drive the connection, and baseline the CTMS screen a monitor will actually plan from. If the granularity changes, the visit status column moves, or a status maps to the wrong label, the diff shows it. No API contract test does, because the contract was satisfied.
The same pattern applies to Site Connect, where an investigator site's consents and site logs flow into the sponsor's eTMF. That is a two-sided system with two different user populations and an exchange in the middle, and the sponsor-side view is the only place the whole thing is observable.
eTMF completeness is a rendered artifact, and it is the one an inspector reads
The eTMF's job is inspection readiness, and inspection readiness is expressed as a set of dashboards and reports: expected documents by milestone, completeness by zone and section, missing artifacts by site and country. Those views are computed from the milestone engine and the expectation set, and then they are rendered.
This is a case where the visual layer is not a proxy for correctness, it is the thing itself. If a completeness metric renders 94 percent when the underlying expectation set says 87 percent, or a zone renders green because a section header collapsed and hid four missing artifacts, no amount of correct data helps you. The number a human reads is the number that drives behavior.
So baseline the dashboards. Seed a reference study with a deliberately incomplete TMF, where you know exactly which artifacts are missing and what the completeness figure ought to be, and capture the rendered dashboards as baselines. Then, critically, promote the text verification layer out of its usual review-only band into the enforcing band for these screens, the same call we make for regulated copy in the PromoMats recipe. A percentage that changed is a finding. In most applications text diffs are chatter; on an inspection-readiness dashboard they are the signal.
The nine-layer verify, tuned for Clinical
Lastest gates a build on nine verification layers, split into bands. The Clinical tuning differs from the CRM tuning in two specific places, and both are worth understanding rather than copying.
| Layer | Band | Clinical-specific reasoning |
|---|---|---|
| visual | ENFORCE | Perceptual diffing, with heavy masking over subject identifiers and dates. The primary gate on dashboards and casebook layouts. |
| text | ENFORCE (dashboards only) | Promoted for completeness metrics, expected-document counts, and status labels. Left in LOG for document lists and free-text fields. |
| network | ENFORCE | A failed call behind a connection handoff renders as an empty panel, which looks a lot like "no findings". |
| url | ENFORCE | Study and site context lives in the route. A silent context switch is a blinding risk, not a cosmetic one. |
| console | ENFORCE | Standard SPA hygiene. |
| dom | LOG | Structural diffs are noisy on data-driven document and subject lists. |
| a11y | LOG | Worth trending; site-facing screens are used by people on unmanaged devices. |
| perf | LOG | eTMF list views degrade as studies grow. Trending catches it before a monitor complains. |
| design | DISABLE | Off until a token set exists to compare against. |
The url layer deserves the extra attention. In a commercial application, a route drifting is a nuisance. In a blinded study, the route carries study and site context, and a context leak is a protocol issue. Gating on redirect trajectory is cheap and the failure it catches is expensive.
Seeding study data without going anywhere near a patient
The obvious objection to automating clinical testing is data, and it is a good objection with a boring answer: none of this needs real subject data, and none of it should have any.
Build a synthetic reference study. One protocol, three sites across two countries, twelve subjects with deterministic identifiers, a visit schedule that exercises the milestone engine, and a TMF deliberately missing a known set of artifacts. Author it once as a loadable package so it drops into any sandbox, and freeze it. Every baseline in the platform suite is captured against that study, which means a diff can only mean the platform changed, because the data provably did not.
The seeded-fixture discipline is the difference between a suite people trust and a suite people mute. Everything above the frozen layer is signal; everything that can drift underneath it is noise you are choosing to accept.
What replay does to the study-startup crunch
The commercial argument here is not really about release regression, though that is where the suite pays rent. It is about study startup, which is the period when a clinical operations team is most time-constrained and most likely to skip verification.
Standing up a study means configuring a casebook, a milestone template, an expectation set, a visit plan, and a site list, then confirming that the whole thing renders and behaves. Done by hand, that confirmation is a day or two of a systems person clicking through screens they have clicked through for every prior study. Done as a replay, it is the standard study checklist running unattended against the new configuration, with the platform baselines already known good, so the only diffs surfaced are the ones caused by the new study's configuration. That is the entire point: the diffs are exactly the thing you wanted to review anyway.
The same run produces the evidence artifact as a by-product. Every layer's verdict is reviewed and approved by a named human, every baseline is versioned with a reason, and every build is a reproducible link. In a GxP environment that chain of custody is not a nice-to-have, it is what separates a passing test from documentation. We made the general case for that in the human-in-the-loop dev cycle, and the compliance-officer version lives in the enterprise compliance guide.
The honest prerequisites
- A sandbox vault plus a password-auth integration user exempt from org SSO and MFA. Same gate as every Vault application, same advice: secure it before anything else.
- A synthetic reference study packaged for repeatable load. This is the real work of standing the suite up, and it is a week, not a quarter.
- Network reachability from the browser pool to the vault. Most pharma sandboxes are private, so plan on a Remote Runner inside the network rather than treating it as an exception.
- For connection testing, both ends provisioned: a CDMS or EDC sandbox connected to the Clinical Operations sandbox. Without both, you can test the endpoints but not the seam, and the seam is the point.
Deployment is self-hosted by default, so screenshots of study screens never leave your network. Combined with synthetic-only data, that removes the two questions a clinical quality reviewer will ask first.
Frequently asked
Do I need a separate suite per study? No, and building one is the mistake this post exists to prevent. You need one deep platform suite against a frozen reference study, plus a short standard checklist that runs per study at startup and after amendments. The platform suite is where release regressions land; the checklist is where configuration mistakes land.
Can this test EDC casebooks directly? It can drive and baseline casebook rendering and data entry flows the way it drives any web application, which catches layout and logic regressions in the form itself. It is not a replacement for the data-level edit-check validation your CDMS team already does. The two cover different failure classes and neither substitutes for the other.
How does this fit with computer system validation? It fits as evidence generation rather than as a separate activity. Versioned baselines, per-layer human approval, and reproducible build links are validation artifacts that fall out of running the tests, which means the testing and the documentation stop being two projects.
What about blinded studies? Run the suite as the roles that matter, including an unblinded and a blinded user against the same seeded study, and baseline both. What you are testing is that the blinded view does not render what it should not, which is a visual assertion by nature. Enforcing the url layer catches the context-leak variant of the same bug.
Start here
Clinical is the Vault application where the manual testing burden scales with your portfolio and the release cadence does not care. Book a release-readiness review and we will separate your platform invariants from your study configuration, size the reference study, and hand back the suite structure plus the auth-bridge plan for your sandbox. Prefer to see the output first? Look at a sample diff report from a real replay run, or read the cross-platform release-testing playbook. The whole thing is open source at github.com/las-team/lastest and self-hosting costs nothing, forever.
The takeaway: you cannot test N studies against three releases a year, and you were never supposed to. Test the platform deeply against one frozen study, test each study shallowly against a standard checklist, and put the assertion at the seams where clinical data actually breaks.