Version 82 represents a major leap forward for Veeva automated testing in TrialGrid. With comprehensive test case generation, full reporting capabilities, and a polished editing experience, Veeva users now have access to the same depth of automated testing that Rave users have relied on for years.

For more information see the release notes for Version 82.

Test Case Views and Reporting

Veeva Test Cases now have the same rich viewing experience as their Rave counterparts. The Test Case view and data view are both available for Veeva drafts, giving you clear visibility into your test scenarios and the data they use. Screenshots can be captured during test runs, and PDF reports can be generated for your validation packages. We've also added AI-generated summaries for Veeva Test Cases and their runs, helping you quickly understand what a test covers and how it performed.

Expanded Test Case Generation

The Veeva Test Case generator has gained significant new capabilities in this release. It now supports Add Event, Add Event Group, and Add Form rule actions, broadening the range of rules you can automatically generate tests for.

A Smoother Editing Experience

We've added editor helpers across all major Veeva step types — event steps, form steps, data value steps, and query steps. These helpers guide you through building test steps without needing to remember the exact syntax. Veeva event steps now include the event group and event for clarity, and there are new steps to check whether events exist or don't exist in a test scenario. Tooltips throughout the editor and run results view display object labels, so you can quickly identify what each object reference means without switching context.

Test Case Management

Veeva Test Cases can now be copied between drafts, just as you can with Rave test cases. This makes it easy to reuse test scenarios across studies or versions. We've also added the ability for users with the 'Can manage Vault settings' permission to view and register Veeva Vaults directly in TrialGrid.

New Diagnostic for Rave 2025.2.0

Diagnostic 0178 has been added to validate Observation Date settings against Rave 2025.2.0 requirements. It ensures that standard form fields only use 'Observation Date of Form' and log form fields only use 'Observation Date of Log/Form', catching misconfigurations before they reach your Rave environment.

This article was auto-generated by an LLM.

Following on from last week when we released 2 new Diagnostics, this week we released 5 new Diagnostics, bringing our total to 108.

Diagnostic #104 checks that %%path/to/resource style Form Help is set correctly. Rave experts will know that if Form (or Field) help text starts with %% then it is interpreted as a link to a resource. In effect the %% is changed into https:// Instead of showing a help text box containing, say, %%MedidataRave/Help/CompletionGuidelines.pdf, Rave will navigate the user to https://example.mdsol.com/MedidataRave/Help/CompletionGuidelines.pdf. This allows you to provide very rich help to your users for things like CRF completion guidelines or standard forms.

Diagnostic #104 can check either that your help for Forms is set to a certain resource like %%MedidataRave/Help/CompletionGuidelines.pdf or it can be check that the resource that a Form points to has a pattern like %%MedidataRave/Help/*. In the latter case %%MedidataRave/Help/Guidelines.pdf and %%MedidataRave/Help/Instructions.html would be valid but %%Help/Guidelines.pdf would not be because it does not match the pattern up to the *

We are in the process of updating Diagnostic #102 so that it can check the content of the resource-style Form and Field help values. Diagnostic #102 checks the validity of hyperlinks that it finds in Field and Form help text and in other text content such as Query messages.

Diagnostic #105 checks that Forms are set to DDEOption "Never". It is provided for clients who know that they are not using Double-Key data entry in their studies.

Similarly #106 checks that Form IsTemplate option is set to False. This is for clients who never use the Form Template functionality.

Diagnostic #107 checks that an all-forms Matrix contains all the Forms that are defined in the Draft. You typically create an All-Forms Matrix for proofing of Forms in PDF output or for annotates. TrialGrid can create an All-Forms matrix for you via its Matrix wizard but it's easy to forget to add a new Form to an All-Forms matrix. Diagnostic #107 makes this easy.

Diagnostic #108 provides the same convenience to All-Forms / Merged / PDF Matrices. Whatever you call them, these are Matrices which are the merger of all other Matrices. The idea is to provide guidance on what the study will look like once completely populated. With a large set of Matrices, keeping this master Matrix updated is a chore. Again, TrialGrid has a wizard to create these in a couple of clicks but this Diagnostic will warn you if you are missing a Folder/Form combination from another Matrix or if you have added a Form/Folder combination to your Matrix which does not exist in any of the other Matrices.

Finally, since we were working in Matrices we noticed that it's possible to add an inactive Form to your Matrix. This is valid but we felt you might want to know about it so we added (Inactive) after the name of the Form in the Matrix editor and also set the Folder/Form combination marker to a red square so you know that you're looking at an inactive Form.

We're constantly working on new things. Watch this space!

This week we released 2 new Diagnostics, added new options to many existing ones and fixed some bugs.

New Diagnostics

First the new: When a customer suggests an idea for a new Diagnostic we determine if it will be useful to all customers. If it is widely applicable we will add it to the product at no cost so long as all other customers get the benefit from it. For this reason many of our ideas for new Diagnostics come direct from customers who are the real experts in Rave study build.

We noticed that our spell check Diagnostic (20) would report on the contents of hyperlinks in help, question texts and Query messages. Complaining about the "DrugNames" in the hyperlink URL "https://www.example.com/user_content/DrugNames.html" isn't that helpful so we stopped the spellchecker from reporting on the contents of hyperlink URLs.

While looking at this Andrew noticed that some of the spellcheck reports were for URLs which were incorrectly formatted or which didn't exist at all. He created Diagnostic 102 to check the validity of URLs embedded in study text strings and also to determine if those web pages or resources such as PDFs actually existed:

In this case the Diagnostic is identifying a badly formed URL (starting with https.// instead of https://) and another that looks valid but cannot be found (http://www.example.com\completion_guidelines.pdf). If you have URLs which are only available for your users on your own network or which are otherwise protected the Diagnostic can be set to ignore these.

A customer reported setting the "Use Current Date Time" checkbox for the default value of a Field which is not a DateTime field can cause Subject PDF generation to fail.

When this happens it's not easy to work out the source of the failure without help from Medidata's service team. Resolving the issue requires a migration to remove this default value setting. We added Diagnostic 103 to identify this rare but very inconvenient situation and to correct it.

Bug Fixes

Some Diagnostics (58, 64, 66, 72 and 98) did not correctly handle pattern-match exclusions like FIELD*, *FIELD and regular expression-based patterns. This affected a very small group of customers and has now been corrected in the Beta environment with release to Production to follow.

New Options

We also updated some of our earliest Diagnostics (Diagnostics 1 to 15) so that by default they now ignore Inactive Forms and Fields. We want to avoid false-positive reporting where possible and findings on these inactive elements can hide issues with active elements which are more important to address. We made this behaviour configurable so you can decide whether you wish to include inactive Fields and Forms in the results of these Diagnostics.

Similarly, we added an option to ignore Inactive Checks for Diagnostics 66 (Checkbox Fields should not have an IsEmpty or IsNotEmpty step in Edit Checks) and 72 (Find duplicate edit checks). All of these changes have been deployed to the Beta site and Production will follow after the normal pre-release cycle.

The Future

We have a backlog of Diagnostics to work on so watch this space for future updates!