New Features: Event-Level Electronic Signature and more...Release Date: June 9, 2017
Release Date: June 9, 2017
We are pleased to bring you the following new features in this week’s release. See details about each feature’s enablement below.
Event-Level More Actions Menu
With this feature, users can perform event-level actions, depending on their security profile. Actions available at the event-level include:
- Event History
- Edit Event date
- Apply Electronic Signature
Event-Level Electronic Signature
Users responsible for electronic signatures can now sign all Submitted forms in an event with a single signature. Forms that are not eligible for signature remain unsigned and will require an electronic signature once submitted. Users can apply event-level signatures by selecting Apply Electronic Signature from the event’s More Actions menu.
Task Bar Displays Applied Filters
With this release, the task bar automatically applies the study, site, or subject filters if available tasks for the user only relate to one filter record. When a filter automatically applies, it appears at the top of the task list so that a user can see the context for the task list. Users cannot remove automatically applied filters.
Source Data Review & Verification Enhancements
When source data verification (SDV) or source data review (SDR) is not completed on a field where SDV or SDR is required, a yellow indicator alerts the user to which fields require SDV or SDR. Once the user completes SDV or SDR, the yellow indicator disappears. Vault also displays a percentage of SDR and SDV completed on a form. Users can now perform SDR and SDV for all items on a form at once.
Casebook Schedule Audit Trail
With this release, users can view an audit trail of all actions on a casebook. Each audit entry includes the timestamp, user name of the user making the change, the affected object, and a description of the event. Users can access the casebook schedule’s audit trail by selecting Casebook History from the casebook schedule’s Actions menu.
Enhanced Custom Actions
Custom actions call an external web server from an actions menu on an object record or document. Administrators can configure custom actions by specifying the URL of the web server and parameters such as the ID of the selected record. In prior releases, only document actions could display within the Vault UI using an in-line iFrame. This release extends this option to object actions.
Additionally, in-line custom actions on both documents and objects now support the transmission of the user’s session ID via a post message listener as a more secure alternative to passing it through the action’s URL.
Object Field Tokens in Messages
This enhancement enables Admins to configure object-specific message templates, including custom object field tokens. Previously, object message templates only supported standard object field tokens, which are shared by all objects.
In 17R1.0, Vault provided Profile Field Level Security allowing Admins to make object fields read-only or hidden at the user’s profile level. With 17R1.3, Admins can configure Atomic Security in addition to profile level security to secure object fields by lifecycle state and/or roles assigned on the object record. In order to configure Atomic Security, an object lifecycle must be assigned to the object.
For a lifecycle state and role, a field can have one of the following configurations:
- Hide: The field is hidden from Create, View, and Edit Forms. When shown in a list view, a field hidden at the State/Role level does not reveal its value (hidden field icon in the UI).
- Read: The field is read-only (Create, View, and Edit Forms, List views, APIs).
- Edit: The field has the same security settings as defined at the Profile and/or DAC level. For example, if a field is editable at the Profile level, the field is still editable in the State and Role level (UIs, APIs).
Object Type Security
This new feature allows access control at the object type level. Admins can assign the Create, Read, Edit, and Delete permissions for each object type in a permission set.
- Read: Gives Read access to records assigned to the Object type (drive record visibility).
- Edit & Delete: Respectively allows the Editing and Deleting of records assigned to the Object Type.
- Create: Allows the creation of records for the Object Type.
For example, the Product object has the Base, Medical Device, and Pharmaceutical product object types. A profile can be configured to provide Read access to Medical Device and Pharmaceutical product types through permission set assignments. This profile can provide Create, Edit, and Delete permissions only to the Medical Device object type.
Profile field level security and object type security can be combined. Based on the previous example, an “External ID” field with “Read” permissions (and no Edit permissions) will be read-only across all Product Object types exposing this field.
In V17R1.0, only the standard roles (Viewer, Editor, and Owner) can be manually assigned on an Object record (assuming Matching or Custom Sharing rules are enabled on the Object).
Starting in V17R1.3, custom roles can be assigned or unassigned on an Object record. A user with Edit permission on a record can manually assign or remove a user or group in a standard or custom role. For example, the Owner of a Deviation Object record (QMS) can assign a user on the object record in the “QA associate” custom application role.
Configurability of Standard Object Lifecycle Roles
With this new feature, the Edit and Delete permissions can be configured on the Viewer, Editor, and Owner standard roles by lifecycle state. A typical business scenario required that Object records are read-only in terminal states of an object lifecycle for most roles, including for the Owner role. For example, a “Product” object record is read-only in the “Obsolete” state for all roles, including for the users and/or groups assigned to the “Owner” role on the record.
Object Type Reference Constraints
Object Type Reference Constraints enable Admins to constrain reference fields that are shared across object types to different subsets of record relationships. This allows users to select reference records only applicable to that type. Previously, the same set of reference records were available to all object types.
Object Type Picklists
Object Type Picklists enable Admins to constrain picklists that are shared across Object Types to different subsets of picklist values. This allows users to see and select only those picklist values that are applicable to a particular object type. Previously, the same picklist with all values were available to all Object Types.
User Task Object Class
The User Task object class enables Admins to configure a new class of objects that can be used to plan, assign, and track work within Vault. Administrators can assign user tasks to users in their vault. When a user task is assigned to a user, that user receives a notification, and Vault displays the user task in the user’s My Tasks view. User task objects can be standalone or associated with a parent object. Relating the user task object to a parent object helps to identify where work is needed. With this release, Vault includes a system-managed Activity object, which provides a single view of all work within a vault, including User Tasks and Workflow Tasks.
Vault now supports the creation of custom printed representations of object data through the use of formatted outputs. This allows users to generate robust printed files combining custom text, images, tables, and formatted representations of their vault’s data. For example, Admins can create printable Audit reports containing related CAPA information, or printable Configuration Change Tickets complete with closure date information.
Vault generates formatted outputs through a user action. When generating a formatted output report, Vault uses a template file to gather and compile data into a formatted report. While Admins only need to build a template once, they can configure a user action to fill out and generate templates for multiple records.
This feature allows Admins to compare the configuration of two vaults. This can help users build a Configuration Migration Package, or to validate that environments are synchronized after package deployment. The output of Vault Compare is an Excel file.
Component Label Visible in Inbound Packages
The component Label value is now visible in the Inbound Package detail page, making it easier for Admins to identify components during migration into a vault.
Lifecycles & Workflows
Object Lifecycle State Types
Object lifecycle state types enable Admins to identify object lifecycle states as either Initial or Complete state types. With this release, “Starting State” is now called “Initial State” for all existing object lifecycle fields. The “Complete State” is optional. As with Document Lifecycle State Type, Object Lifecycle State Type is used to enable other features in Vault, such as User Task Object Class, which is also in this release.
Vault Loader CSV Size Limit Increase
In this release, we enhanced Vault Loader to handle much larger inputs. The CSV file size limit for Vault Loader has increased from 10MB to 1GB.
Flash Reports makes it easy for users to distribute reports and avoid waiting for large reports to execute. Users with permission can now schedule any report on a daily, weekly, or monthly basis and opt to distribute that report directly to the email inboxes of other Viewers and Editors of the flash report. In addition, when users access the flash report in Vault, it loads instantly by using the most recent cached results instead of re-executing the report.
Feature Enablement Details
|Event-Level More Actions Menu||Auto-On||EDC|
|Event-Level Electronic Signature||Auto-On||EDC|
|Task Bar Displays Applied Filters||Auto-On||EDC|
|Source Data Verification & Review Enhancements||Auto-On||EDC|
|Casebook Schedule Audit Trail||Auto-On||EDC|
|Enhanced Custom Actions||Configuration||All|
|Object Field Tokens in Messages||Auto-On||All|
|Object Type Security||Configuration||All|
|Configurability of Standard Object Lifecycle Roles||Configuration||All|
|Object Type Reference Constraints||Configuration||All|
|Object Type Picklists||Configuration||All|
|User Task Object Class||Auto-On||All|
|Lifecycles & Workflows|
|Object Lifecycle State Types||Configuration||All|
|Component Label Visible in Inbound Packages||Auto-on1||All|
|Vault Loader CSV Size Limit Increase||Auto-On||All|
|1 In vaults where Allow Inbound Data Packages is enabled.|
See the following explanations for feature enablement options:
|Auto-on||Automatically activated and no configuration is required before using the feature; note that in some cases, a new feature is dependent on another feature that must be enabled or configured.|
|Admin Checkbox||Admins must turn on the feature with an Admin checkbox. Note that some “Auto-On” features have a checkbox setting that hides the feature; these will show “Auto-On.”|
|Configuration||Admins must configure the feature (separately from an Admin checkbox) before it is available to use or is active; for example, a Clinical Programmer must create an Item Definition of a certain new Item Type.|
|Support||On/off option controlled by Support.|