- Home
- Release Notes
- SX R12
SX R12
RELEASE DETAILS
Product Name | DRYiCE SX |
Version Number | Release 12 |
With this release, we are delighted to announce the launch of new features and enhancements for improving user experience, increasing configurability and auditability.
The key highlight of this release includes the introduction of the Progressive Web Application (PWA), which provides a dynamic, modern UX for users on any screen, on any device. Other highlights include auto logging of approvals and tasks created for Standard changes for better auditability, enhanced CI & Asset search capability on the Asset and Config Board, and validation of task date fields in ad-hoc tasks for error-free change implementations.The scope of this release extends to the Consumer Portal, Service Board, Foundation, Incident Management, Problem Management, Change Management, Asset and Config Management, AMS Board, and Notifications Module.
Consumer Portal
-
The display of "Add to Cart" button on the “Offering” section of the Home page can now be enabled or disabled from the Service Board on the basis of the ‘Work Item’ type and the ‘Delivery Mode’ of requests. This will provide the flexibility to configure the “Add to Cart” button wherever applicable.
-
The UI of the Asset and Config Board has been enhanced with the introduction of sorting, filtering, and search capabilities. This will now enable users to quickly identify all assets across the organization’s infrastructure for effective control and monitoring.
Service Board
-
A new date-time field has been introduced on the ordering information page to allow users to enter the date and the time of any question related to offerings in the Provide Information section. This will ensure the input of all necessary information for fulfilling requests efficiently.
-
SPCM Audit logs will now capture all the approvals and tasks created for fulfilment plans in Standard Change type offerings. This will improve auditability of Standard Change offerings.
-
The “Expected Start Date” and “Expected End Date” fields on Standard change offerings will not be auto populated with the dates entered at the time of submitting change forms. This will allow requesters to enter the time of the implementation correctly>
-
A new drop-down field has been introduced on the "SPCM" module, providing the flexibility to select catalog or CI-based Standard Change offerings and directly configure their corresponding approval and task plans. Once the configuration has been completed, the catalog-based and CI-based offerings will be governed through the SPCM and CMDB modules respectively. This will provide the flexibility to create any type of Standard Change offering from the SPCM module.
-
The “Implementation Plan” question on the “Standard Change Template” has been renamed as "Attachment" and made non-mandatory. Also, the “Implementation Plan Details” section has been changed to "Multiline Textbox" type instead of "Textbox” to improve the readability of the text.
-
The "Optional Components" and "Self-Service" action buttons on the offerings detail page will be displayed only if they have been configured for the offerings on the Service Board. This will remove display of redundant buttons, as only those items will be visible on the offering which are relevant to it.
TMS Board
-
The “Expected Start” and the “Expected End” date fields in ad hoc tasks will no longer be auto-populated from their parent change requests. A validation message will be displayed, enabling users to enter the correct dates in the respective fields.
-
The “Task activity” details will be automatically saved in the “Activity Journal” section of the TMS module instead of the Work Item corresponding to each task. The saved information will help in auditing activities in the future.
-
While creating tasks for support groups in any of the modules, the activity of mandatorily assigning the tasks to specific users in that group will no longer be necessary. This will ensure first time right assignation to the relevant group leading to faster completion of tasks.
Foundation
-
All users and associated members of a group will now automatically inherit all roles from the group. This will save time and effort on creating roles individually for each user.
-
The capability to edit existing “Approval Group” names and create descriptive group names with the increase of character limitation from 25 to 50 will now help to create groups on a granular level improving the accuracy of assignations.
-
Upon linking a group to a company, all users belonging to that group will get automatically associated with the company. This will help in automating the process, removing the need for user-level manual linkage.
Incident Management
-
A new capability has been introduced to enable CI-based Incident creation through integrations and automatically assign those tickets based on the defined chain entity in the Asset and Config board/CMDB. This will allow the automated creation of CI-based incidents directly from the event management tool.
Problem Management
-
The “Actions” icon on ‘Under Investigation Problem Tickets’ will have an additional option called ‘Specify Vendor Tickets’ for adding, updating or deleting vendor records associated with the ticket. This will display all vendor dependencies associated with the request in a transparent manner.
Change Management
-
APIs have been introduced to integrate external ITSM tools with the “SX Hub”
to ensure that the fulfillment of change requests happens at SX and the status is communicated to the external ITSM through e-bonding.
-
In Change Audit log, the “Exp Start Date” and the “Exp End Date” labels have been modified to “Scheduled Start Date" and “Scheduled End Date" respectively. The change in the nomenclature will ensure capturing timelines accurately and improve users’ experience of accessing the functionality.
-
The attachments for “Implementation” and “Backout” plans will be visible and downloadable from the Change form during the change life cycle. This will enable users to instantly refer to the information when needed for better decision-making.
-
To change the status of any “Emergency Change” from “Draft” to “Under Review”, it will be mandatory to associate incidents with change requests. This will help in improving the accuracy of the post-implementation audits.
All processes
-
The “Provide Attachments option will be available even after the incident is moved to “Fixed”. This will allow to capture post incident review, including the high-level resolution steps, timelines, and recommended actions. This will allow the “Problem Management” team to initiate detailed RCA by accessing the information in the attachments.
Notifications
-
On reopening fulfillment tickets, email notifications will be triggered to the requestor and to the assigned support group to inform them of the change in status. This will update both the parties in a timely manner, thus allowing them to respond appropriately
-
Upon task reassignment, email notifications will be automatically triggered to the relevant support teams for seamless workflow and efficiency. This will make it easier for the support team to follow up with their assigned tasks without the need to constantly monitor the queue for updates.
-
On updating comments in the Activity journal of SX through integrations with external ITSM tools, notifications will be triggered to all the configured stakeholders. This will ensure that updates are notified to the integrated ITSM tools.
-
Notification Admins” will be able to access the “Notification Configuration UI” and create notification templates for companies that fall within their authorization. Once the notification template has been saved, a preview will be automatically generated on the UI, which will help notification admins to accept or discard the templates.
-
A conditional matrix has been introduced for task notifications to trigger notifications to the correct recipient based on the predefined conditions given below:
Scenario 1: Notifications triggered to ‘Assigned’
Condition 1: If the task is assigned to the group for the first time, or if it is reassigned from another team
AND
Condition 2: If the task is assigned to the individual assignee for the first time, or if it is reassigned from another individual
Scenario 2: Notifications triggered to ‘Group’
Condition 1: If the task is assigned to the group for the very first time, or if it is reassigned from another team
AND
Condition 2: If the task has not been assigned to any individual
Scenario 3: Notifications triggered to ‘Assigned’
Condition 1: If no changes to the assigned group
AND
Condition 2: If the task is assigned to the individual for the first time, or if it is reassigned
This will ensure that only the correct individual or group gets notified.
-
Upon assigning a fulfillment ticket to an individual, the related email notification will only be triggered to the assignee and not to the group to which the assignee belongs. This will remove redundant notifications and increase the efficiency of the process.
-
Upon changing the status of an RFC change request from “Draft” to “Under Review”, a default email notification will now be sent to requestors. This will keep the requesters updated on the status of the ticket.
DRYiCE SX™ offers a unified marketplace for enterprise services fulfilled by best-in-class ITSM practices.
For product-related inquiries, please reach us at support.dryice.ai@hcl.com