New Features in 26R1 Limited Releases
26R1 Planned General Availability: April 10 & 17, 2026
25R3.5 Release Date: March 6, 2026
25R3.4 Release Date: February 20, 2026
25R3.2 Release Date: December 19, 2025
We are pleased to bring you new functionality with each limited release. These release notes are updated with upcoming new features one week before the limited release date.
Enablement Changes: The enablement of each feature is subject to change from release to release. For limited releases in the same general release, we will update this page. Enablement may also change before the general release. Refer to the Release Impact Assessment for the most up to date enablement for a general release.
Data Review
Features in this section are changes to the Review tab, a working area for clinical research associates and data managers, or to review functionality within the Data Entry tab.
Protocol Deviation Enhancements: CTMS-Managed PDs 25R3.2
Use Case
This feature improves alignment between Veeva EDC and Veeva CTMS. Since the Clinical Operations-EDC Connection is one-directional, changes made to a Protocol Deviation (PD) in EDC can inadvertently overwrite data managed in CTMS. By restricting editing capabilities in EDC for connected studies, this enhancement establishes CTMS as the primary management tool for Protocol Deviations.
Description
For studies connected to Veeva CTMS, this update changes how users interact with Protocol Deviations in EDC. Once a PD is created in EDC, the ability to edit the deviation fields within EDC is disabled.
When viewing a CTMS-managed Protocol Deviation, the following applies:
- The Edit button is disabled. Hovering over the button displays a tooltip explaining that the record is managed in CTMS.
- Users can view the full details of the Protocol Deviation and its audit trail.
Users can manually inactivate a PD in EDC with a new option labeled Inactivate Protocol Deviation in the Action menu. This option is useful if the deviation has already been marked as inactive in CTMS.
Selecting Inactivate Protocol Deviation triggers a confirmation dialog where the user must provide a Reason for Change. If the deviation was not already inactive in CTMS, the connection will update the status based on the change made in EDC.
Enablement & Configuration
Contact Veeva Support for enablement. Immediately after the release, connected studies will no longer be able to edit Protocol Deviations in EDC.
Clinical Coding
The following are new features for Veeva Coder, the clinical coding area for Veeva Coder.
Display Freeze & Lock States in Coder for Queries 25R3.2
Use Case
Currently, Coder users did not know if the EDC data associated with a coding request is frozen, which leads to delays when querying frozen data only to find out through a Site query response that the data must be unfrozen. This feature adds clear visual indicators in the form of banners in the Query Panel in Veeva Coder, enabling coders to quickly identify data that requires action from other teams. This improves the Coder workflow and speeds up the process when data needs to be unlocked or unfrozen for querying purposes.
Description
This enhancement displays banners within the Query Panel in Coder to display the Locked or Frozen status of the source EDC data for a given verbatim. The behavior when data is Locked remains the same and queries cannot be posted to locked data. The banners are displayed above the Search Query Templates box or the ‘Submit a Query…’ free-text input field. Depending on the view mode, Coder users can be provided with the following information:
Locked Data
-
List Mode error banner text: “Queries can’t be posted, closed, or autoclosed because the corresponding form is locked.”
-
Grouped Mode error banner text: “The corresponding forms are locked and cannot receive queries.”
In Grouped Mode view, the banner will display as long as at least one form in the group is locked.
When data is locked, the Search Query Templates box (if present) and the Submit a Query text input field are disabled, preventing query actions. This is a change to the existing design where, instead of an error banner, the information about the form being locked was displayed directly in the ‘Submit a Query…’ text input field, which no longer displays that information.
Frozen Data
-
List Mode informational banner text: “Data is frozen.”
-
Grouped Mode informational banner text: “The corresponding data is frozen.”
Note that in the **Grouped Mode **view, the banner will display as long as at least one verbatim in the group of code requests is frozen.
Unlike with locked data, when data is frozen the query input fields remain enabled. Freezing affects the data source but does not prevent the ability to enter a query.
Enablement & Configuration
This feature is automatically available.
Coder Query Audit Trail Enhancements 25R3.2
Use Case
Currently, when a user has access to both the Coder and Review tabs and edits a message associated with a Coder-related query from the Review Tab, the system’s audit trail doesn’t accurately reflect the edit as a separate event in Veeva Coder. This makes it difficult to track the history of changes to the query’s message.
The enhancement ensures that all changes to a Coder Query message are tracked with a clear, separate audit entry, improving audit completion and meeting regulatory compliance and audit needs.
Description
With this feature, the Coder Audit Trail creates a new, separate audit entry whenever the message of a Coder-related query is edited, rather than simply updating the original audit entry with the new message. This change ensures that both the original query message and all subsequent edits are clearly recorded and visible in the Audit Trail. It also improves consistency between the Item Audit Trail in EDC and the Audit History in Coder.
Enablement & Configuration
This feature is automatically available.
Coding Administration
The following are new features for Coder Tools, the administration area for Veeva Coder.
Update Coding System Label to Veeva Coder 25R3.2
Use Case
In line with the recent update of Vault application branding from Vault [Application] to Veeva [Application], the product name for the Coding System and all system references now use the updated name, Veeva Coder. This change ensures consistency in product naming across all Veeva applications.
Description
This feature updates the product name displayed for the Coding System in all system references, including Coder Tools > Study Settings. With this release, the label for the Coding System is updated from Vault Coder to Veeva Coder.
Enablement & Configuration
This feature is automatically available.
Imaging
The following are new features for Veeva EDC Imaging, the imaging exam module for Veeva EDC.
Imaging: Update DICOM De-identification Profile 25R3.2
Use Case
DICOM images often contain a large volume of metadata, including sensitive patient health and identifying information (PHI/PII). This feature ensures that the system’s DICOM de-identification process and profile are current with the latest DICOM standards (specifically, 2025c). The automated de-identification process now covers newly defined tags, ensuring the system’s ability to reduce risk and maintain compliance.
Description
Veeva EDC Imaging’s security profile has been updated to include all tags defined in the DICOM standards up through release 2025c. This ensures the Tag Browser correctly displays all available tags.
The existing de-identification process is updated to include new DICOM tags.
- For each DICOM file, the system will identify new tags flagged for ‘DEID’ (De-identification).
- The original values of these new tags will be replaced with de-identified dummy values.
This update is a background change to the system’s data management and does not include any changes to the existing user experience (UX) or workflow.
The list of the DICOM tags that have been incorporated into the de-identification profile from release 2024c through 2025c:
| Attribute Name | Tag | Dummy Value |
|---|---|---|
| Ethnic Group Code Sequence | (0010,2161) | SQ |
| Ethnic Groups | (0010,2162) | UC |
| Gender Identity Code Sequence | (0010,0044) | SQ |
| Gender Identity Comment | (0010,0045) | UT |
| Gender Identity Sequence | (0010,0041) | SQ |
| Histological Diagnoses Code Sequence | (0008,1304) | SQ |
| Montage Channel Label | (0040,B03F) | LO |
| Montage Name | (0040,B03B) | LT |
| Name to Use | (0010,0012) | LT |
| Name to Use Comment | (0010,0013) | UT |
| Person Names to Use Sequence | (0010,0011) | SQ |
| Primary Diagnosis Code Sequence | (0008,1302) | SQ |
| Principal Diagnosis Code Sequence | (0008,1301) | SQ |
| Pronoun Code Sequence | (0010,0015) | SQ |
| Pronoun Comment | (0010,0016) | UT |
| Secondary Diagnoses Code Sequence | (0008,1303) | SQ |
| Sex Parameters for Clinical Use Category Code Sequence | (0010,0046) | SQ |
| Sex Parameters for Clinical Use Category Comment | (0010,0042) | UT |
| Sex Parameters for Clinical Use Category Reference | (0010,0047) | UR |
| Sex Parameters for Clinical Use Category Sequence | (0010,0043) | SQ |
| Third Person Pronouns Sequence | (0010,0014) | SQ |
Enablement & Configuration
This feature is automatically available.
Study Design & Configuration
Features in this area apply to Studio, the study design and configuration area for Veeva EDC.
Studio Casebook Version Update 25R3.2
Use Case
New fields seen when creating and editing casebook versions help Study Designers provide better references for amendments. The casebook version name and external ID can now be updated during the development and testing of post-go-live changes.
Description
When editing or creating a casebook version, the external IDs can now be set uniquely to each new casebook version. Study Designers can update the casebook definition (version) name, reason for change, description, and external ID for non-published study versions.
New optional fields, Description and External ID, are available in the Create New Version dialog. The fields Reason for change and External ID are now included in the Edit Casebook Version dialog, allowing designers to amend these values while updating the study design. Also, for clarity, the title of the Edit dialog has been updated to Edit Version Properties: [version number].
The field lengths are enforced with on-screen error messages when exceeding the character limits:
- Name (128)
- Reason for change (255)
- Description (256)
- External ID (128)
The properties of previously published versions and versions with a Validating status are viewable from the new View Version Properties Studio menu option. Selecting this opens the View Casebook Version dialog as read-only.
Enablement & Configuration
This feature is automatically available.
Enforce Valid Derived Item Configurations 25R3.2
Use Case
New Studio restrictions and validations help Study Designers properly configure system edit checks, progressive display, and default data related to Derived items, preventing production issues caused by these improper Studio configurations.
Description
System Edit Checks (Item Properties)
When the Item Type of an item is changed to Derived and saved, EDC now automatically archives any active system edit checks associated with that item (for example, Required, Future Date, and Range checks). This ensures that Required, Future Date, and Range checks are not auto-generated in Data Entry for items which cannot be revised by site users. For previously added edit checks on the derived item, a new dialog informs the designer which system edit check settings will be archived.
Progressive Display
The system now prevents the use of derived items in Progressive Display rules when the visibility is set only to Include in Extracts. When revising a derived item and the Display Visibility property only specifies Include in Extracts, and Progressive Display rules are included, Studio will automatically archive the Progressive Display rules, displaying a new Impacted Objects dialog. The Progressive Display section will then be hidden from the item or item group’s Properties panel.
For existing, invalid, configurations (on either an item group or item), a warning icon and notification appears within the drag and drop editor. A warning banner with the Clear Progressive Display button is displayed within the Properties panel, allowing users to correct the configuration and archive the rules.
Default Data
Derived items will no longer appear as available columns to configure Default Data. Items that are configured as Default Data cannot be changed to be a Derived item type.
If Derived items were previously included within Default Data, the column will now appear with a warning icon and orange highlighting. A red banner at the top of the grid will notify users that they are required to delete the column in order to save changes to the Default Data configurations.
Warnings will also be included when running the Casebook Validation.
As part of this feature, new eraser icons appear next to the item columns, allowing study designers to remove an entire item and the whole column of values from the Default Data configurations.
Enablement & Configuration
This feature is automatically available.
Display Item's Previous Submit Value in Email Messages 25R3.2
Use Case
Study Designers can now configure the previous value of an item to be included within the Message of Send Email rules. Seeing the previous and current value within the email body can be particularly useful for sending emails related to Adverse Event (AE) and other forms.
Description
When configuring User Defined Rules in Studio, the .previous_submit_value__v item attribute is now available as a token for including in email messages. Study Designers will see the additional token within the Action section of the Send Email rules and can use this token to provide the item’s previous data value within the body of the email.
Example: ${Custom.@Form.igAE.AESER.previous_submit_value__v}
Enablement & Configuration
This feature is automatically available.
Study Administration
Features in this section apply to System Tools or EDC Tools, a study-level administration area for Veeva EDC.
Redesign Rule Job Output File 25R3.2
Use Case
The output files of the Run Rules job (EDC Tools) have been redesigned to provide more comprehensive details about rule execution results. This change helps Study Designers and Data Managers gain a more complete understanding of the expected behavior when running revised rules.
Note: This feature includes updates to the .csv files that take effect in the 25R3.2 limited release. More updates in the upcoming 25R3.4 limited release will consolidate the individual .csv output files into one single file with separate tabs, and will provide additional enhancements.
Description
When running the Run Rules job, the resulting output files now incorporate the following updates:
| File | Column | Rule Type | Summary of Change |
|---|---|---|---|
| All | All | All | Object names are now displayed instead of labels |
| For studies where the Study Language is enabled, the files will now be translated. | |||
| rule_details.csv | Action | All | "None" Action: An Action of "None" is generated for rules that were either selected but did not execute (e.g., bound form did not exist) or ran but resulted in no action. |
| Add Form, Add Event, Add Event Group |
|
||
| Open Query |
|
||
| Create Protocol Deviation, Create Integration Record |
“Created” replaces "Added" to describe create actions | ||
| Set Derived Value |
|
||
| Set Subject Status | New Actions include Subject Status History Updated, Subject Status Rolled Back (replaces “Unset to [Status]”), Prior Status Rolled Back, and Skipped | ||
| Rule Result | All | This column is now populated for all rule types. All rules except Set Derived Value will display TRUE or FALSE. Set Derived Value rules will display the Derivation Result. | |
| create_delete_dynamics_details.csv | All | All | Dynamic object names are now displayed in their full hierarchy (e.g., Add Form rules will now show the name of the specific Event and Event Group where the action occurred). |
| Action | All | Action labels have been updated to match the rule_details.csv file | |
| dynamics_summary.csv | All | All |
Column headers have been updated to match the corresponding Action labels.
Note: The [Object] Added columns will not be usable in the 25R3.2 release, as they will not be incremented and will remain 0. |
| errors.csv | N/A | N/A | Permutation errors during rule execution are now captured and included |
| Errors are now identified using GUID, which replaces the technical Failure Reason message |
Enablement & Configuration
This feature is automatically available.
Clinical DataBase (CDB) & EDC Clinical Reporting
The following are new features for the Veeva CDB application, EDC Clinical Reporting (the Veeva Clinical Data solution for data cleaning and reporting), or both.
Availability: Clinical DataBase (CDB) is only available to CDB license holders. Contact your Veeva Services representative for details.
New Third-Party Data Type Validations 25R3.2
Use Case
Validations on data type ensure that the data adheres to the values described by the manifest, resulting in higher quality data and error detection during import.
Description
The system now provides new validations on numeric and text data types configured in the manifest, as well as support for MySQL BigINT numbers (i.e., numbers with greater than nine (9) digits).
Validations for the text Item Definition will ensure that the configured length is greater than zero (0) and less than or equal to 1500. New warnings D-039 for greater than 1500 and D-040 for length less than one (1) will display and set the values in the manifest if they do not conform to the minimum and maximum length for a text field.
Numbers defined as Float in the manifest will have new validations with warnings D-041 to D-046 to ensure that the Item Definition length is at least one (1) and does not exceed 24 digits. The configured minimum and maximum values cannot be less than -999,999,999,999,999,999,999,999 and cannot be greater than 999,999,999,999,999,999,999,999.
Numbers defined as Integer in the manifest will have new validations with warnings D-047 to D-052 to ensure that the Item Definition length is at least one (1) and does not exceed 18 digits. The configured minimum and maximum values cannot be less than -9,223,372,036,854,775,808 and cannot be greater than 9,223,372,036,854,775,807.
Enablement & Configuration
This feature is automatically available at the time of the release.
Manifest Builder Updates 25R3.2
Use Case
Enhanced features in the Manifest Builder ensure better data quality and provide a better experience for users building a manifest file (.json) to import third-party and OpenEDC data.
Description
The Manifest Builder has been updated with the following features:
- Required field validations in the Manifest Builder for the following data types:
- Text (length is required)
- Float (length and precision are required)
- Date, Date Time, and Time (format is required)
- Codelist (codelist is required)
- Configuration validations will display in the Manifest Builder:
- Text length must be between 1-1500 characters
- Integer length must be between 1-19 digits
- Integer minimum must be greater than or equal to -9,223,372,036,854,775,808
- Integer maximum must be less than or equal to 9,223,372,036,854,775,807
- Float length must be between 1-24 digits
- Float precision must be between 0-7 digits
- Float minimum must be greater than or equal to -999,999,999,999,999,999,999,999
- Float maximum must be less than or equal to 999,999,999,999,999,999,999,999
- The ability to upload codelists:
- New codelists or adding items to existing codelists
- Import template CSV available
- The text default is now set to 500
- Adding a new item to the manifest Item Mapping will no longer display the row in error on creation
- When data type is changed, any entered properties will be cleared
Enablement & Configuration
These features are available automatically at the time of the release.
Third-Party Data Import Notification When Pending Approval 25R3.2
Use Case
Users will now receive a notification when the package they uploaded is pending approval and requires action within CDB Workbench.
Description
The user who uploads a third-party data package will now receive a notification if the package is pending approval and requires action (approval). This occurs regardless of whether it is the first package from this source or a change to the previously approved package manifest.
This feature applies to both Veeva EDC and OpenEDC studies.
Enablement & Configuration
This feature is automatically available at the time of the release.
Additional Fields for the Clean Patient Tracker 25R3.2
Use Case
Additional columns allow for better review of subjects in a study and understanding of where in the schedule of events the subject is, especially when using repeating event groups.
Description
The Clean Patient Tracker now includes columns for Substudy and Latest Event Group to provide more context and filter options when viewing the tracker.
Enablement & Configuration
This feature is automatically enabled at the release.
Filter Menu Redesign for CQL Listings 25R3.2
Use Case
The operator option as a drop-down makes it more clear which operator the user selected.
Description
The Operator selector is now a drop-down menu.
Enablement & Configuration
This update is automatically enabled at the release.
CDB Grid Improvements 25R3.2
Use Case
Improvements to screen size utilization in a listing enhances the experience for users–either those using smaller screens, or wanting to focus their view of data better by moving the cell details panel to a new window while still viewing the listing rows, making reviewing data easier.
Description
This release improved listing screens to use the available space more efficiently. Users can now pop out the cell details panel, which will automatically maximize the grid. Users can also use a new dialog to show and hide columns, so you no longer need to select columns one at a time to hide or show individual columns.
Enablement & Configuration
This changes apply automatically at the time of release.
Support JDrug Coding Dictionary in CDB 25R3.2
Use Case
For studies with Veeva Coder that use the JDrug coding dictionary, the availability of JDrug in CDB supports more robust listings that include Japanese coded terms for drug forms such as Concomitant Medications.
Description
JDrug Coding Dictionary values are now available in CQL, Listing Builder, SFF, and Raw exports. Updates to Raw exports include new columns for DictionaryType and UserCodedBy, for all forms with MedDRA, WHODrug, and JDrug dictionaries configured. New JDrug dictionary values will apply to forms configured in Veeva EDC with the JDrug coding dictionary.
Enablement & Configuration
This feature is automatically available.
My Observations Assignments Filter in Review Listings 25R3.2
Use Case
Being able to filter a Review Listing to show only assigned Observations enables users to easily find and action the Observations assigned to them.
Description
Review listing filters have a new option, Observation Assignment, which filters to display only Observations assigned to the current user.
Enablement & Configuration
This feature is automatically available upon the release.
Update Review Listing Timing Thresholds 25R3.2
Use Case
Updates to the refresh timing allow for longer running listings to refresh on a limited basis.
Description
Review listing timing thresholds have been updated so that listings that run for longer than 30 seconds, up to 5 minutes, will be refreshed on a daily basis after 50 consecutive runs of greater than 30 seconds. CDB will automatically disable any listings that run over five minutes.
Enablement & Configuration
This feature is automatically enabled at the release.
Role Management & Security
Features in this section are enhancements to the System Tools > Role Management and System Tools > Users areas, as well as changes to standard Study Roles, security, and access control in Veeva Clinical Data.
New Query Team 25R3.2
Use Case
Three new specialized Query Teams offer more granular control over the assignment and management of queries.
Description
With this release, Veeva EDC introduces three new Query Teams: Medical Monitoring, Medical Review, and Pharmacovigilance. These new teams are now available as selectable options within the Team dropdown menu when administrators create or rename custom roles. Additionally, these teams can be selected in the “Query Team for System Queries” dropdown located in the Study Settings within Studio. No standard roles have been added to these new teams.
Enablement & Configuration
This feature is automatically available.
Connections & Integrations
Features in this section are new connections or integrations with Veeva Clinical Data or enhancements to existing ones.
Safety-EDC Connection: Connection Configuration Available for Every EDC Vault 25R3.2
Use Case
To configure the Safety-EDC Connection to connect one or multiple Veeva EDC Vaults to a Veeva Safety Vault no longer requires contacting Veeva Support.
Description
The configuration of the Safety-EDC Connection can now be done by Vault Owner and Safety Administrators without involvement of Veeva Support.
Enablement & Configuration
This change applies automatically.
EDC Migrator
Features in this section are new features for Veeva EDC Migrator.
Migrator Support for Signing Casebooks with Open Queries 25R3.2
Use Case
Currently, during the migration process, if a casebook contains an open query, the Migrator prevents it from being electronically signed. This happens even if the Enable Sign with Open Queries setting in EDC is enabled for the study. This feature eliminates this behavior, ensuring that migrated studies retain the correct signature status as defined in the source data when the study is configured to allow signing with open queries.
Description
This enhancement allows the Migrator to apply an electronic signature to a casebook, or form, even if it contains an open query, provided the corresponding EDC setting is enabled in the target study.
During the migration, the Migrator checks if the Enable Sign with Open Queries setting is enabled for the study in EDC Tools > Study Options:
- If the option is disabled, the Migrator’s existing behavior holds, and signatures are not applied to casebooks with open queries.
- If the option is enabled, the Migrator proceeds to apply the signature as indicated in the migration input data, without preventing it due to the presence of an open query.
Enablement & Configuration
This feature is automatically enabled, however, for it to work during migration, the study option Enable Sign with Open Queries must be enabled in the migrating study.
Safety Integrations: Suppress Safety Case Data Transfers during EDC Changeovers 25R3.2
Use Case
When migrating studies from legacy EDC systems into Veeva EDC, Safety Cases initiated by the legacy EDC already exist in the Safety system. Loading the safety-relevant data from the legacy EDC during the migration into Veeva EDC would initiate a first Safety Case transfer from Veeva EDC and either create duplicate cases in the Safety system or clutter it with additional Inbox items that have to be linked to existing cases.
This new feature allows the migration of safety data into Veeva EDC or perform release procedures without generating unnecessary transfers of Safety Case messages to the Safety system. This reduces significant load on the Safety Case processing during any EDC migration or release procedures while the regular follow-up process will be automatically reinstated once any changeover procedures are completed.
For the Safety-EDC Connection, this new capability will additionally allow the suppression of the creation of Safety Case follow-up messages, if desired, for example, during the release procedures.
Description
This feature introduces logic to support the migration of EDC data and involves:
- Initiating, which would initiate a duplicate initial Safety Case transfer or also to suppress unnecessary follow-up messages resulting from updates to EDC, for example during release management.
Before starting the EDC migration procedures a final full safety scan has to be run in the legacy EDC system to ensure that all follow-up messages, which are composed due to EDC data changes, are transferred to the Safety system. During the migration, EDC safety data, relevant safety case metadata, and a migration indicator is uploaded to Veeva EDC by the Vault Owner. As part of the final migration procedures, a full ad-hoc Follow-Up Scan job will be executed in Veeva EDC. For studies using the Safety - EDC Connection, the cases in the migrated study are now automatically linked to the existing Veeva Safety case without the creation of any unnecessary Inbox items in Veeva Safety. The additional subject information will, however, be updated in Veeva Safety for review on demand by the Safety team. For studies using the E2BLink, the cases will create an E2B.XML, which is not transferred to the AS2 gateway, but mimics a successful transmission.
Safety Cases are now registered with the Safety system. Follow-Up Scan jobs will execute as scheduled and create follow-up messages if there are changes to any Safety Case data.
For the Safety-EDC Connection, this new capability can also be used to suppress Safety Case data transfer if desired. For this, a full ad-hoc Follow-Up Scan has to be performed, the indication of being a halted case for transfer has to be set by the Vault Owner for all affected Safety Cases in Veeva EDC. After the changeover procedures have been finished, another full ad-hoc Follow-Up Scan must be performed. While this full scan will not result in follow-up messages to Veeva Safety, it will automatically reinstate the regular Follow-Up Scan job for actual Safety Case updates initiated by the site.
Enablement & Configuration
This change applies automatically