We are excited to announce that the Mount Zion Release has been tentatively scheduled for the week ending Friday, July 2nd!
This release will occur on or after Thursday, July 1st.
These are the features and enhancements that may be included in the Mount Zion 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
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.
If the Admin accepts the value (or values), then the phase will no longer be be blocked.
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.
DocuSign Signature Phase Proxyship
PM2-7567 DocuSign Signature Phases will support proxyship for Signatories.
A proxy will be substituted for an out-of-office Signatory at the time that Signatory becomes the active sequenced participant.
The DocuSign envelope will be sent to the proxy.
Any Docusign tabs placed for the out-of-office Signatory will be transferred to the proxy.
Currently, if no user in a user group has the proper role, Location, and Contract Type permission set to be assigned to a workflow, then an Admin within the user group will automatically be assigned.
PM2-8103 Admins will be able to enable or disable Admin fallback functionality for each user group.
Admins can enable or disable Admin Fallback Placement in the User Placement Options panel when creating or editing a user group. By default, Admin fallback functionality will be enabled (as it is today).
Hovering over the next to Admin Fallback Placement will reveal a tooltip:
Specify whether an Admin in the User Group (if present) should be placed in another role as a fallback if no user in the User Group is able to be placed based on an exact match of role, Contract Type, and Location.
PM2-7322 When creating or editing a user group, Admins can decide if a user placement from that group should consider permission sets that are not designated as Default Assignee.
For the Default Assignee Permission Sets to consider field, an Admin can select All Permission Sets or Only Permission Sets with Default Assignee Designation.
By default, All Permission Sets is selected.
Hovering over the will reveal a tooltip:
When attempting placement of Default Assignees from this User Group, specify which user Permission Sets should be considered. Regardless of the selection, if no matches are found on the Default Assignee list, the system will assess all Permission Sets from all User Group members.
When the ranked Default Assignee list is exhausted, other Permission Sets will be considered as a list of potential users is generated.
Other user placement rules will remain unchanged.
Super Admin Role
The Super Admin role is being developed in conjunction with several in-app administration tools that will allow users with that role to change global settings. This will reduce risk by ensuring that only a handful of designated users may edit or manage settings with the potential of affecting all organizations tenant-wide.
This will empower customers to customize their CLM tenants to better meet their unique needs while preventing unauthorized changes and maintaining compliance and data integrity.
The first in-app administration tool we are releasing will be email management.
The Super Admin role will not be available in the UI. To have it applied to a user in your organization, contact your MediTract CLM representative.
Users with the role of Super Admin will be able to manage and configure system email notifications.
Super Admins will be able to see system email notifications in a table, which can be filtered and sorted.
Regular Admins will have read-only access to this table.
Super Admins will be able to toggle notifications on and off, at the organization level.
The toggle applies to all system email notifications; individual notifications cannot be toggled off at the organization level, although individual users can toggle off individual system notifications in their account settings.
The toggle does not apply to in-app (bell) notifications.
Super Admins will be able to add custom text to the body of a system email notification.
They will not be able to edit or remove the hard-coded email body.