We are excited to announce that the Mount Xanadu Release has been tentatively scheduled for the week ending Friday, May 28th!
This release will occur on or after Thursday, May 27th.
These are the features and enhancements that may be included in the Mount Xanadu Release. Please note that this list is subject to change.
The prerelease notes are essentially a summary, or abstract, of the release notes that will be published the day of deployment. If you read the prerelease notes and not the release notes, you will miss details regarding major features, as well as minor changes and defect fixes that cannot be published this far in advance of a release.
These items are currently undergoing testing for quality assurance. If our QA team deems an item unfit, it will not be released. This means that we might not release everything on this list.
To avoid surprising you, we will not release any major change that is not on this list.
We will still publish full notes on the day of the release. Here’s what you’ll find in those that you don’t see here:
A complete list of the features and updates that were actually released
Detailed instructions on how to use new features
Bug fixes and defect fixes
Minor tweaks to the UI that improve the user experience without substantially changing it
PM2-8114 To improve performance, the worklist will display a maximum of 500 rows per page.
If a user enters a number greater than 500 in the Results Per Page field, they’ll see a message asking them to enter a lower number.
PM2-6423 Block Phase Trigger
A new workflow trigger type, Block Phase, will allow Admins to configure workflow templates so that if a predefined value or range of values is entered in a form field, then the phase will be blocked until an Admin intervenes.
Only an Admin can take action on a phase in a blocked workflow.
If a user enters a value that will block the phase, they’ll see a warning message.
If the user submits that value, then the phase will be blocked. The Phase Manager and Admins will be notified.
An Admin will unblock the phase, after which they will be sequenced in as a Reviewer.
Alternatively, the Admin may cancel or retract the workflow, or skip the remaining participants and complete the phase.
The Admin will address the triggering value (or values) and submit their review.
The Phase Manager will be notified that the block has been resolved.
A new workflow status, Blocked, will be available in the Filter Table widget in the Worklist and Reporting > Workflows.
Blocks and resolutions will be recorded in the Workflow History and, where applicable, the Executive Summary.
Workflows & Contracts
PM2-7011 Permission Overrides in Workflows & Contracts
Users will be able to apply contract permission overrides when selecting a Primary, Secondary, or Tertiary Responsible Party.
This functionality will be controlled by a backend toggle at the tenant level. By default, it will be OFF for all customers. To have it turned on, an Admin can contact your organization’s MediTract representative.
The list of Responsible Parties available for selection will include every internal user (i.e., any role except External Party).
If a user selected as a Responsible Party lacks sufficient permissions for the contract, then they will be granted Contract Moderator permissions for that contract.
Admins will be notified of the permission override by email.
Time Tracking (TERMS 2.0)
PM2-8134 Workflow History on Timesheets
The Workflow History panel will be displayed in timesheets (which are functionally workflows). The workflow history will list the following information:
Date & time
First and last name of user who took action
Phase in which action was taken
Location Matching Logic
This functionality was originally released with Mount Yale, and then rolled back due to performance issues. It may be made available with the Mount Xanadu Release.
We created a new type of location-matching logic, Full Match on Selected Leaf Nodes, that can replace the existing Permission Node system.
The current method, the Permission Node approach, requires Admins to grant broad privileges to users for them to access specific contracts that span multiple entities, departments, and sites.
The new approach is more intuitive and more precisely matches a user's access to contracts and workflows with their permissions as set by the Admin.
This functionality will be controlled by a backend toggle at the tenant level. Turning it on will substantially affect user permissions, and in many cases require a comprehensive reconfiguration of user permissions.
Upon release, there will be no immediate impact to existing CLM customers!
Professional Services will work with each customer to ensure that users' Contract Location permissions are reconfigured in a way that meets their needs.
We will eventually sunset the current Permission Node system.
PM2-7013 Full Match on Selected Leaf Nodes
To be considered a match, the comparison location (for example, a Reviewer’s Contract Location permissions) must contain every node that corresponds to the selected leaf nodes* in the reference location (for example, the Contract Locations of a workflow where that Reviewer may be added as a Phase Participant).
*A selected leaf node is any selected node that doesn't have a child node selected.
Location-matching logic does not affect User Roles or Contract Type permissions; it only applies to permission checks associated with Contract Locations.
Location-matching logic applies in the following situations:
PM2-7349 Selecting a workflow template
Approval of a request workflow
Selection of a user available to take part in a workflow
PM2-7171 Phase management
PM2-8032 Proxy placement
PM2-7446 Placement from a User Group
PM2-7324, PM2-7440 Access to a particular contract
Selection of a user on a workflow template
PM2-7472 Phase management
PM2-7473 Trigger placement
Population of lists of contracts
PM2-7324 Contract Library
PM2-7441 Vendor/Provider records
PM2-7441 Selection lists available for contract linking and Initiation
Population of lists of workflows1
PM2-7439 Vendor/Provider records
Selection of available Approved Language in a workflow2
For most roles, access to a given workflow (and thus display of that workflow in a list) is dependent upon involvement.
Approved Language location matching has always relied on this system, and will continue to do so for the foreseeable future.