What's New in 17R1

Pre-Release Date: March 28, 2017  Release Dates: April 14 & 21, 2017__

We are pleased to bring you Vault 17R1. Read about the new features below. You can find information on enabling new features in 17R1 Feature Enablement Details.

EDC

Vault EDC is a new electronic data capture application that gives users the ability to collect and manage clinical data.

Note that EDC is not included in Feature Enablement Details as it is only available to new EDC customers. The features described here Auto-On in the EDC application.

Casebooks

Vault EDC uses casebooks to house all data related to a specific subject in a study. Casebooks display a schedule of all study events for a subject and contain all forms for that subject. Vault EDC’s casebooks include the casebook schedule: this is a clickable event timeline, which can expand to show all forms for an event.

Queries

Vault EDC includes both system- and manually-created queries. Queries provide traceability, including an item-level audit trail, comments, and status indicators.

Task Bar

Users can use Vault EDC’s task bar to quickly view any tasks assigned to them, such as open queries and overdue forms. The task bar displays important task details and links to the area in Vault EDC where users can complete a task.

Expanded Task Bar

Source DataReview & Verification

Clinical Research Associates can perform source data review and verification tasks with a single click in Vault EDC. Vault EDC includes status indicators to show the status for source data review or verification.

Data Freeze & Lock

Data Managers can preserve data at any given point during a study using either data freeze or data lock. Data freeze preserves data, but it still allows additional actions like source data review or query creation to take place. Data lock prevents any modification or action upon data.

Vault Objects

Field-Level Security on Objects

Field-Level Security (FLS) on Objects allows Admins to control Read and Edit permissions on individual fields within an object, making certain fields hidden or read-only to users with specific security profiles.

For example:

  • Integrations: Some vaults include integrations in which Vault imports data from an external or legacy system into object records. An organization may want to make these fields read-only to ensure that users do not overwrite the imported data. By assigning business users to security profiles that do not include edit access on these fields, an Admin protects the data, but still allows editing by super users and the integration tool itself.
  • Protecting Sensitive Information: In some organizations, Vault holds Personal Information Identifiers (PII) and other sensitive information that needs to be hidden from many users to protect privacy and confidentiality. An Admin can allow Read and Edit permission on security profiles that apply to the relevant users, but hide the fields entirely for other security profiles.

Configuration

This feature uses custom security profiles and permission sets to control access. Within a custom permission set, Admins can configure field-level security from the Objects tab. The standard security profiles do not use field-level security.

Removing the Edit permission makes a field read-only. Removing the Read permission makes a field hidden. A permission set must include the relevant object-level permission before it can include a permission at the field level, for example, you cannot assign Edit permission on the Name field within the Location object if the permission set does not include Edit permission for the Location object.

Certain standard fields have built-in field-level security that is not editable, for example, Created By and Created Date are never editable. Vault also prevents Admins from configuring field-level security on certain standard fields to ensure that core functionality works well.

Access Enforcement

Vault enforces field-level security through the user interface (including reports, dashboards, and Vault Loader), the APIs, and VQL. Within configurations that use both field-level security and Dynamic Access Control (DAC) for Objects, field-level security can further restrict access. For example, Thomas may have access to edit specific Location records (through DAC), but not have access to edit the Name field (through FLS).

Dynamic Reference Constraints

An Admin can define a dynamic reference constraint on a reference field to restrict the records that can be selected by filtering the records based on the value of another field. The reference field with a dynamic constraint defined is the controlled field, while the field used in the constraint criteria is the controlling field. The user must first enter data in the controlling field, so that the selected value can be used in constraining the selectable records in the controlled field. For example, the Product object may reference the Manufacturer and Distributor objects. The user would select a manufacturer first. The list of distributors available to select from would be constrained by the selected manufacturer. Learn more.

Depending on the object relationships, both parent reference and object reference fields can be constrained, and a sequence of constraints can be defined on multiple reference fields such that the user must enter data in one field before entering data in the next field and so on. 

Dynamic Page Layouts

Dynamic Page Layouts enables Admins to declare that some page sections are visible only during specific states of an object record’s lifecycle. The feature simplifies the page layouts in cases where certain fields or related records become relevant only in specific stages of a business process.

Parent Object Field Filters

In this release, Admins can define filters on Parent Object fields to constrain the list of object records that a user can choose from when creating a child record or associating records in a many-to-many relationship. For example, in a simple many-to-many relationship between Product and Study objects, an Admin can define a filter on the Product parent field in the join object to ensure that users only select products in Approved status.

Within Related Object sections on an object record detail page, Vault now displays object reference fields as clickable links. This functionality lets users navigate directly to related object records. For example, a Product record includes a related Studies section with a column showing the CRO responsible for each study. Now, a user viewing the Product record could click to navigate directly to the CRO record detail page.

Relabeling Filter Records in Referenced Object

Previously, the reference constraint feature was called “Referenced Object Filter” and displayed as “Filter Records in Referenced Object” in the object field configuration section. In this release, the feature has been relabeled to ‘Constrain Records in Referenced Object.”

Object Types

Custom Tabs by Object Type

Custom tabs allow you to organize and expand the primary navigation bar, providing users with quick access to object records. In this release, Admins can create custom tabs that are specific to a single object type, making it even easier to tailor tabs to specific business scenarios. Within an object type custom tab, all filters and search are specific to records of that object type.

Page Layouts by Object Type

Object types enable organizations to differentiate records within an object based on their functional purpose. Object types typically share many fields, but each type includes a subset of fields specific to its function. For example, the Audit object could include External Audit and Internal Audit object types. Each Audit record belongs to one of these types.

The Page Layouts by Object Type feature gives Admins the option of configuring separate page layouts for some or all object types within an object. Object type-specific layouts can only display fields that belong to the type. Type-specific layouts also have their sections for grouping fields and showing related object records or documents.

Object types without a dedicated page layout will continue use by the base object page layout.

Required Fields by Object Type

Object types enable organizations to differentiate records within an object based on their functional purpose. Object types typically share many fields, but each type includes a subset of fields specific to its function. For example, the Audit object could include External Audit and Internal Audit object types. Required Fields by Object Type allows Admins to declare that some fields are required only for records of a particular type.

Lifecycles & Workflows

Case Change Functions

This release introduces new functions for automatically updating text fields. These functions will be particularly useful for the Export File Name field, used when exporting a Form 2253 compliance package binder for submission to the FDA, which requires all file names be in lowercase.

  • upper(text) sets the text string to all uppercase characters.
  • lower(text) sets the text string to all lowercase characters.

These functions are available in:

  • Update Record Field state entry actions on object lifecycles
  • Update Record Field steps in object workflows
  • Set field using formula state entry actions on document lifecycles

Object Record Access Control by Lifecycle State

In a recent release, we introduced custom roles with editable permissions for objects. This release moves that functionality to the object lifecycle level and allows permission edits at the lifecycle state level. For example, when a Product record moves into Approved state, users in custom roles on that product can no longer edit or delete the record. Learn more.

Note that the standard Viewer and Editor roles are not configurable, but Owner is. 

Object State Entry Action Change State of Related Records’ States

Entry actions are automatic actions that occur when an object record enters a specific lifecycle state. With this release, Admins can configure entry actions to change the lifecycle state of a related record. For example, in a PromoMats vault, when a Product record enters Withdrawn state, all related Marketing Campaign records would move to Inactive state. This type of entry action only supports inbound relationships, which means that it can change the states of object records that reference the primary object record or child records of the primary object record. This feature will support additional relationships in a future release.

Object State Entry Criteria Based on Related Object Records’ States

Entry criteria are conditions that an object record must meet before it can enter a specific lifecycle state. Admins can configure entry criteria to verify that related object records are in a specified state before allowing the primary object record to enter a state. This functionality is available for inbound or outbound relationships.

For example, the Campaign object is a child of the Product object. Entry criteria on Campaign could prevent the campaign from entering Ready for Publication state before the Product is in Approved state.

Update Record Fields Workflow Step & Entry Action

These powerful new configuration options enable Admins to systematically set the value of an object record field as part of a workflow or state change. This new feature works much like the Set field using formula entry action for document lifecycle states: Admins set the value of a date, number, or date field using an Excel-like formula language that includes functions to calculate new dates and text strings. The feature also supports setting picklist and yes/no fields.

For example, a Product record’s state change to Approved could automatically update the Approval Date to the current date and the Due for Renewal date to two years from the current date.

Calculated Task Due Date in Object Workflows

Admins can now configure object workflow task due dates based on a number of days offset from either Workflow Start Date or Task Creation Date. This new configuration option enables Vault to calculate task due dates, rather than prompting the Workflow Initiator to enter a date. Using a calculated due date is more efficient for users and provides fewer opportunities for incorrect data entry.

Cancelling Object Workflows Reverts Record to Original State

In this release, we’ve improved Vault’s handling of object records when users cancel an in-progress workflow. In past releases, cancelling a workflow did not change the object record’s lifecycle state, even if the record had moved into a new state as part of the workflow. In this release, cancelling a workflow reverts the object record to the state it was in when the workflow started.

Reporting

Export Reports to PDF

With this enhancement, users can export reports as PDF with the optional, configurable Report Export Cover Page. PDF exports maintain grouping and default report styles, and include the page number and report name on each page. Learn more.

New Report Display Options

This enhancement introduces new options for how reports display. When creating or editing a report, users can now modify the labels of columns and filters without making changes to the overall vault. In addition, users can remove the Name columns, which Vault previously required for every reporting object.

This new functionality supports two primary scenarios: meeting the formatting and column naming requirements of third parties, and improving user experience when filters are not easily understood.

Reporting Supports Multiple “Down” Objects

This enhancement allows users to include multiple “down” objects, such as documents and child objects, in a single report. With multiple down object reporting, you can view a list of object records, like Product, as well as related documents and Product Country object records. See example report type configuration below.

We have designed the report viewer so that the primary object row, down objects, and up objects are visually distinct.

Authentication & User Setup

Cross-Domain Users & Authentication

This feature provides an ability to add existing (home domain) users to remote domains as “cross-domain users.” These users can continue to log in with their existing home domain user name and password (or corporate identity provider for SSO users), but can access vaults on remote domains if granted access.

Hide User Information

This feature allows organizations to hide identifying user information from a specific group of users. By configuring a custom security profile and permission set without the new View User Information permission, Admins can create a group of users who cannot see or search for user names of users not sharing their same email address domain

With this release, Vault provides better support and compliance for customers collaborating with external users who should not access identifiable user information.

Manage Multiple Applications within a Vault

This feature introduces better visibility and control for vaults that use an application suite, rather than a single application. Examples include RIM (Registrations, Submissions, and Submissions Archive) and Quality (QualityDocs and QMS). These vaults must have separate licenses for each application.

In this release:

  • Adding or updating a user requires the Admin to indicate which applications the user is licensed for and the License Type at the application level. These selections are in addition to the standard, application-level License Type.
  • In Admin > Settings > General Settings, the License Information section lists out applications installed in the vault and the user license levels associated with each application.

There will be no impact to vaults that are not part of a suite, including eTMF, PromoMats, MedComms, and Platform vaults.

Forgot User Name

This release introduces a new feature for users who have forgotten their Vault user name. In past releases, these users needed to reach out to an Admin. Now, these users have a self-service option for retrieving a forgotten login name.

Note that this change will not be visible until the 17R1 release to all PODs on April 21. This change won’t appear on pre-release vaults.

Password Reset Changes

With this release, when users request a password reminder, they will receive an email with reset instructions and a link to enter a new password. Unless users set the new password, their original password remains unchanged.

Password reset uses a new message template, rather than the existing template. Admins should transfer any customization to the new message.

Note that this change will not be visible until the 17R1 release to all PODs on April 21. This change won’t appear on pre-release vaults.

In Admin > Users & Groups > Security Profiles > Users tab, we’ve removed the rolodex links (alphabetical links) that appear above the user list. This change will result in significant performance improvements for the Domain Users page on multi-vault domains.

Vault Loader

Vault Loader Field Selector

Users can now specify exactly which fields to include in the output for a Vault Loader extract. The default extract behavior will remain the same, but users can now override the default behavior. Field selection is supported for Document, Document Version, User, and Object extracts.

Vault Loader Extracts Name & External ID for Related Object Records

Vault Loader CSV extracts now identify object references using the external_id__v and name__v fields, rather than just the internal id field. This change affects both parent object fields and object reference fields.

For example, a Marketing Campaign object record extract might look like this:

id name__v product__c product__c.name__v product__c.external_id__v
OBE000000000303 Cap Your Cholesterol 00P000000000202 CholeCap CC
OBE000000000304 Ever Wonder 00P000000000101 WonderDrug WD

Limit CSV File Size for Vault Loader

In this release, Vault Loader enforces a file size limit for uploaded CSV files: 10 MB. This limit improves performance.

Configuration Migration

Component Comparison for Configuration Packages

Component Comparison allows Admins to view the details of a proposed configuration change prior to deploying an inbound package using Configuration Migration Packages. This feature compares the component included in an inbound package with the same component as currently configured on the target vault. Within the first step of the Review & Deploy action, Admins can use the View comparison link on any Update deployment action to open the Component Comparison view.

Configuration Migration Package Comparison Export

The new Package Comparison is an exported Excel workbook that describes the differences between an inbound package and the current vault configuration. Users can request the Package Comparison from the inbound package Actions menu. By running prior to deployment, Admins can verify that the imported package contains the expected configuration changes. By running after deployment, Admins can use the comparison to document evidence of successful deployment.

Component Label Visible in Outbound Packages

The component Label value is now visible in the Outbound Packages user interface, making it easier for Admins to identify components when adding them to outbound packages for migration.

Configuration Migration Packages: Enablement Change

In V16, customers needed to contact Veeva Support to enable Configuration Migration Packages. In this release, Admins can enable the feature themselves from Admin > Settings > General Settings.

UI Changes

Improved My Vaults Page with Cross-Domain Support

The My Vaults page supports access to vaults across multiple domains. Users can sort and filter the vault tiles, as well as mark specific vaults as favorites for ease of navigation. Each vault tile now provides information on domain name, last accessed time, and application (PromoMats, RIM, etc.). Admins can set this up to show a customer logo on each tile.

Improved Vault Selector with Cross-Domain Support

Users with access to more than ten (10) vaults will see an enhanced vault selector. The five (5) most recently accessed vaults appear in the drop-down list. A search bar with type-ahead suggestions lets users find any of their vaults. For users with cross-domain access, the domain name shows with the vault name.

Login Page UI Update

As part of our ongoing project to update the Vault UI, we’ve refreshed the login page. This enhancement does not change behavior.

Note that this change will not be visible until the 17R1 release to all PODs on April 21. This change won’t appear on pre-release vaults.

New Vault Color Palette

We have updated the page header color scheme throughout Vault to present a cleaner and more modern look. This change also affects the Admin area, the external document viewer, and the My Vaults page.