DRYiCE SX R8

This release of DRYiCE SX includes enhancements in the Consumer Portal, Work Item Board, Fulfillment, Incident, Problem and Change processes, Asset and Config Board, Rules Board, Service Desk Board and Foundation.

With this release, we have improved the operational efficiency with the introduction of new capabilities such as automatic creation of incident tickets, CI based approvals, and documenting updates to the CMDB during Normal, Standard and Emergency changes. Also, processes have been optimized with introduction of new workflows, audit logs, and more configurability to mitigate risks and increase maturity. Towards this end, we have brought in new functionalities, which are put forward in this release note.

Consumer Portal

• Now change request approvers will be able to add ad-hoc approvers to change approval requests in the ‘Pending for Approval’ state. This will enable them to add relevant approvers in real time.
• The ‘Favicon’ icon for the SX portal has been updated to enable users to intuitively find the SX tab when multiple tabs are opened on the same browser. 
• Now the names of external links displayed under the ‘External Link’ icon on the home page of users will be automatically translated to the user's selection of preferred language.
• Now, on selecting the ‘Open’ option from the ‘Status’ drop down filter on 'My Request' and 'Service Desk' pages, all requests that have been referred back will also be displayed in the list of open items. This will allow users to access and initiate work on the requests that have been referred back to them.
• Now, once an approval request has been triggered from a change request, the associated CI/Asset name will become visible to the designated approvers in the ‘Service/CI’ column on the list view of approval requests; similarly, the associated Class name will be displayed on the right hand side of ‘My Approvals’. This will enable change approvers to assess the potential impact of a proposed change request before they choose to accept or reject the request. 
• A capability to sort approval requests by date has been introduced on the ’My Approval’ page to enable approvers to sort requests in order of their request date.
• Now, on raising a service request on behalf of someone else, a notification containing the order details will be sent to the user requesting the service and also to the user for whom the service has been requested. This will ensure that both the parties are aware of the request and have all the details of the requested service available.
• Now, requesters will be able to cancel requests that have been referred back by the approver from their 'My request' page. This will enable requesters to view the requests that have been referred back and cancel them, if required.
• A new column 'Service/CI Name' has been introduced on ‘My Request' page to display the CI or service name based on which the requests have been created. This will enable fulfillers to understand the impact of the requests and act accordingly.
• Now, if designated approvers are not available to approve pending requests, users with administrator role will be able to delegate the approvals to new approvers in the ‘Delegatee’ field on ‘My Delegation’ page after the existing approver’s name has been recorded in the ‘Delegation for’ field. This will ensure that approval requests are not put on hold indefinitely due to the absence of the approver.   
• Now, requesters will be provided with a unique number corresponding to the requests raised by them, enabling them to track requests with just the number. 

Consumer Portal and Foundation Portal

• A new capability has been introduced in the ‘Foundation Portal’ to configure bulletins in a desired sequence while they are being created or edited. This will enable application administrators to publish bulletins on the consumer portal in the order of their significance. 
• A new capability has been introduced in the ‘Foundation Portal’ to configure 'External links' in a sequence of choice while they are being created or edited. This will allow application administrators to show external links in the order of their preference under the ‘External link’ icon on the consumer portal.
• Now, application administrators will be able to configure external links as icons on the ‘Icon tray’ instead of showing them as links in the dropdown list of the ‘External link’ field on consumer’s home page.  This will enable consumers to view, identify and access the resource from the ‘Icon tray’, improving their user experience.

Consumer Portal and Service Board

• Now, catalog managers will be able to translate the description of service components into any of the languages enabled on SX through the language activation module on the service board. This will enable consumers to view service components on the offering details page in their preferred language, improving their experience.

Consumer Portal and Change Management

• A new functionality has been introduced to enable catalog managers to configure and publish pre-approved standard change templates from the service board in the service catalog. This will  enable consumers to request a standard change from the consumer portal using the catalog.

Work Item Board

• Sticky filters have been introduced on the ‘Fulfilment’ work item board so that the filters selected by the fulfillers on the list view of the ‘Fulfilment’ work item board’ are retained even after a fulfilment record has been updated. This will allow fulfillers to continue working on the same filtered list even after taking action on records in the list. 
• Now, on clicking on any of the incident numbers listed under the ‘Related Work Item’ icon, users will be redirected to the corresponding incident. This will enable users to access all related incidents from a single location.    
• A new ‘Copy Incident’ icon has been introduced on the top righthand corner of an existing incident form to enable incident managers and users to copy the information contained in ‘Impacted service/CI’, ‘Issue description’, ‘Additional information’ and ‘Urgency’ fields so that they can be pasted to their corresponding fields on a new incident ticket. This will allow incident managers and users to populate the fields on the new incident ticket from an existing ticket, in one go, saving time and increasing their efficiency.    
• A new ‘Source’ field has been introduced on the problem form to enable users raising problem requests to select the most appropriate source of the problem from all available options including ‘High Priority’ incident, ‘Unresolved Incident’, ‘Recurring Incident’, ‘Proactive Analysis’
• Now, on creating and saving problem or change requests, users will continue to remain on the same page enabling them to review the saved changes and if required, continue working on the same request.
• Now, upon clicking on a request number in the ’Related Work Item’ icon of the fulfilment, incident, problem or change form, the users will be redirected to their corresponding fulfilment, incident, problem, or change requests. This will enable users to quickly navigate to the relevant requests from the form itself.
• Now, the tasks listed in the ’Tasks’ section of requests will become editable only in the sequence in which they were configured through the fulfilment plan. This will enable execution of the tasks only in the correct sequence as support users will be able to change or edit the status of a task only when all the previous tasks have been marked as completed or cancelled.
• A new search criteria called 'Impacted CI' has been added on the ‘Change’ work item board to enable change users to filter change requests based on the CI information. The list view of change requests will now have an additional column called ‘Impacted CI’ to display CI information associated with each request. This will enable change managers and users to understand about the CIs impacted once the change is implemented
• Now, users with access to incident and problem modules on the ‘Work Item Board’ will be able to search for requests based on impacted CIs by selecting 'Impacted CI' value from the drop down list on the search bar. Name of the 'Impacted CI' will also be visible on the right hand side section of the screen so that users can quickly view the CI that has been impacted due to the corresponding incident or problem ticket.
• Now, upon clicking on the ‘Relate Work Item’ icon visible on the left hand side of problem and change forms, users will be provided with an option to select ‘Same Impacted CI’ value from the search drop down values. On making the selection, a list of requests that have been impacted by the same CI will become visible, enabling users to select and relate them to the relevant problem or change requests. This will enable users to identify and search for requests that have impacted the same CI and relate them.

Service Board

• Now, while a service is being configured on the ‘Service Board’ the catalog managers will be able to select the level of complexity of the configured service from dropdown values listed in the 'Default Complexity' field in the ascending order of service complexity (simple, medium, complex). The drop down list will reduce the probability of mistakes in comparison to a free text field.      
• A new capability has been introduced to enable catalog managers to preview and edit all the existing translations for services configured on the ‘Service Board’. This will allow catalog managers to make any changes incorporating any feedback related to the translation..
• The audit log on the ‘Service Board’ has been enhanced to capture modifications made by catalog managers to ‘Reminder Notification End Date’, ‘Reminder Notification Initiation’, ‘Reminder Notification Interval’ in the ‘Reminders’ section of service details. This will document and make the changes made to ‘Reminders’ available for audit purposes. 
• The audit log on the ‘Service Board’ has been enhanced to capture changes made by catalog managers in the SLAs on the service details page of a service offering.  This will document and make the changes available for audit purposes.
• An additional parameter 'Role' has been introduced in the entitlement section of service details to enable catalog managers to control access to service offerings based on user roles.
• Now, catalog managers will see a new error message ‘Changes are not allowed in Deployed status’ if they try to upload a new image or icon for a deployed service from the service board. This will inform the catalog manager that the icon/image for a deployed service cannot be changed and they will need to change the state of the service to inactive before doing so.

Service Desk Board

• A new capability has been introduced on the ‘Service Desk’ board to enable users to create new incidents by copying details from an existing incident. The  copy feature will  save  time and effort spent on creating similar incidents from scratch, enhancing the efficiency of the service desk.

Asset and Configuration Board

• A new capability has been introduced on the ‘Asset/Config Board’ to enable configuration managers to configure approval workflow for change requests raised for a specific asset or CI. In order to create the approval workflow configuration managers will have to select the CI record under the ‘Asset/Config Board’ to open the Asset/Config item page. On clicking the ‘Approvals’ label on the opened page, configuration managers will need to specify details including ‘Rule Name’, ‘Change Type’, ‘Level of approval’, ‘Type of approval’, ‘Weightage’ and set any criteria related to “Environment’, ‘Consumer Company’, ‘Support Company’, ‘Category’ and ‘Location’ if applicable on the approval rule. Filling up these fields will map the CI based change approvals automatically to the approval group defined in the process.
• A new read only field 'Model Name' has been introduced on the CMDB page for assets/ both assets & CIs, combining 'Manufacturer', 'Model', and 'Version' fields. This will enhance the amount of information about assets and CIs in the CMDB. 
• Now, asset and configuration managers will be able to relate CIs with any of the relationship types available on SX, thereby allowing relationships between CIs.

Rules Board

• Checks and validations have been introduced on the ‘AMS Board’ to prevent the creation of rules with the same ‘Company’, ‘Module’, ‘Service’, ‘Component and Assignment for’, or ‘Company’, ‘Module’, ‘Class’, ‘CI and ‘Assignment for’. This will help catalog managers in creating unique rules thus reducing redundancies.

Foundation Portal

• A new capability has been introduced on the ‘Foundation Portal’ to enable super admins to activate or deactivate SX ‘Knowledge Center’ on any tenant of an instance from the ‘Company’ module.
• The ‘Employee Id’ field in the ‘User’ module of the foundation portal has been changed to varchar from numeric type to enable organizations using characters in their employee ids, onboard their employees.
• The ’Alias’ field under the 'Company' module on the Foundation Portal has been made non mandatory to enable application administrators to configure a company without having to assign an alias to it.
• Now, users with a new role of 'Broadcast Manager' will be able to access 'Advertisement', 'Bulletin', and 'External Link' sections within the General module of the Foundation portal thereby controlling access to configuring advertisements, bulletins and external links.
• The ‘Summary’ field on the add/edit bulletin page of the ‘Foundation Portal’ has been replaced with an ‘URL’ field to enable application administrators to configure URLs with bulletin messages. On clicking on the bulletin on the home page, consumers will be redirected to the configured URL.   
• Now, app admins will be able to configure up to 400 characters long description for bulletin messages which will allow them to put in more details for the end users.

Incident Management

• A new capability has been introduced in the ‘Incident’ work item board to enable support users to raise incidents for a service or a configuration item as well. This will provide more flexibility as earlier incidents could only be raised against services.
• A new ‘Copy Incident’ link has been introduced at the top right hand corner of the incident form to enable incident fulfillers, incident managers or service desk users to click on the link and copy the existing incident details into a new request. This will save time and energy creating similar requests from scratch.
• Now, whenever an incident is reopened, a notification carrying all relevant details of the incident will be triggered to all the members of the 'Assigned group'. This will ensure that all members of the associated group are updated that the incident has been reopened and  it needs their attention.
• Now, catalog managers will be able to configure automatic tasks for critical incidents so that when an incident has been approved as critical, the configured tasks will be automatically created.

Change Management

• A collision detection functionality has been introduced in the ‘Emergency Change’ workflow to enable change requesters to check for any conflicts with maintenance, blackout windows or any other scheduled changes while proposing emergency changes. This will enable them to avoid any conflicts while scheduling the such change.
• A new ‘CMDB Update’ stage has been introduced in the ‘Normal Change’ workflow to enable implementation group members or change managers to record any change or update to the CMDB that were made during the ‘Normal Change’ process. This will ensure that all the necessary details about changes made to the CMDB will be recorded for conducting an effective Post Implementation Review (PIR).       
• A 'CMDB Update' stage has been introduced in the ‘Emergency Change’ workflow to enable change and configuration managers to record any change or update to the CMDB during the ‘Emergency Change’ process. This will ensure that all changes are recorded and made available for ‘Post Implementation Review’ (PIR). 
• The ‘Emergency Change’ workflow has been enhanced with the introduction of the ‘Post Implementation Review (PIR)’ stage to enable change managers and change users to review and audit the change on a later date. This will provide a systematic approach to evaluate and provide feedback, maturing the change management process.
• 'Major' and 'Minor' change types have been removed from the change process and instead we have introduced ‘Normal’, 'Emergency' and 'Standard' changes as options to be proposed by change proposers. This will further mature the change management process, aligning it with industry best practices.
• Now, change proposers will be able to propose change requests only based on configuration items. This will enhance the efficiency of the change management process as the approvals will be triggered to the correct support group.  
• A risk assessment form has been introduced in the ‘Emergency Change’ workflow to enable change requesters to assess and record the risks associated with change requests while they are being raised. This will increase the maturity and efficacy of the ‘Emergency’ change process.
• Now when the status of a change request is moved to either ‘Cancelled’ or ‘Under PIR’ state, notifications corresponding to the change in status will be triggered to both the change users and change proposers. 
• This will keep the stakeholders updated on any change in status of the ticket allowing them to take the appropriate action. 
• Now a ‘Check for Conflict’ link has been introduced on the ‘Normal Change’ and ‘Emergency Change’ form to enable change proposers to check for potential change conflicts before submitting change requests. On clicking the link, change proposers will be able to see all the change requests conflicting with the proposed change on the same CI within the same date range. This will enable change proposers to take an informed decision to either ignore the conflict or reschedule it. 
• A ‘CMDB Update’ step has been introduced in the ‘Standard Change’ workflow to record details of an implemented change. Now, change proposers will have to provide ‘Closure Code’, ‘Closure Comments’ after clicking on the ‘End Implementation’ button from the hamburger menu to complete the change request.  This will ensure that all ‘Standard Change’ requests follow a documented process that has been reviewed and approved by the change management team.
• Now, audit logs will automatically capture any update or change in the information contained in 'Impacted CI', 'Urgency', 'Reason for change', 'CMDB update needed', 'Risk assessment form', 'PIR form' fields of Standard, Emergency and Normal Change forms. This will ensure that the Change management process is audit ready.
• The UI of the ‘Create Change’ page on the ‘Work Item Board’ has been enhanced. The drop down values in the ‘Risk Assessment’ field have been changed to ‘Low’, ‘Medium’ and ‘High’ and the drop down values in ‘Reason for Change’ field have been sorted in the alphabetical order to make it easier for users to search and select the appropriate risk level.   
• Now, Level 1 approvers will have to provide the ‘CAB’ date while approving a ‘Normal Change’ or an ‘Emergency Change’ request. The CAB date will not be allowed to be a past date or a date beyond the expected start date of the change.
• This will ensure that the proposed changes are reviewed by the CAB before they are implemented.

Task Management

• Now, upon clicking on the ‘Tasks’ icon displayed on left hand side of the fulfilment, incident or change form, the tasks configured by catalog managers from the ‘Fulfilment Plan’ section will become visible to support users in an ascending order by their sequence number.
• A task sequence column has been introduced in the window from where ad-hoc tasks are created to enable fulfillers to check the sequence in which tasks have to be completed while working on  incident, fulfilment, problem, or change requests.
• Now, support users will also be able to search requests based on the content in the ‘Short Description’ and ‘Additional Information’ fields of requests by selecting the option 'Keyword' in the drop down field of the search bar on the task module. This will introduce the contextual search capability enhance and search flexibility on the task module of the work item board.

​​​​​​​Fulfillment Management

• Now, upon auto-fulfilment or auto-rejection of fulfilment requests that were put 'On Hold' due to pending 'Customer action', the resolution notes will be auto generated as 'Auto-fulfilled' or 'Auto-Rejected' and captured in the activity journal. This will ensure that the details are recorded and made available for an audit at a later date.

​​​​​​​Notification Engine

• Logo, footer, signature and instance hyperlinks on notifications can be configured based on company. This enables further personalization of notifications for tenants.
• Now, portal links have been added in all notification templates, enabling users to navigate seamlessly to the correct portal upon clicking on the link.
• A new policy called the ‘n Strike Policy’ has been introduced for fulfilment requests that are put on 'Hold' due to the reason 'Customer action required'. This will enable application administrators to configure the maximum number of reminder notifications that will be sent out to customers before the requests are completed automatically. This will prevent delays in the fulfilment process beyond a reasonable period of time, increasing the efficiency of the fulfilment process.

​​​​​​​​​​​​​​Approvals

• Now, whenever a designated approver becomes unavailable, all approval requests pending with them will be auto approved or rejected according to configured rules. The ‘Auto Approval’ or ‘Auto Reject’ message will become visible under the approval section on ‘My Approval’, ‘Work Item Board’, ‘My Request’ and ‘Service Desk Board’ of SX.  This will ensure that approvals are not put on hold indefinitely and all stakeholders in the fulfilment process are kept updated.

DRYiCE SX™ simplifies employee experience through a unified digital marketplace for all IT and business services.

For product-related inquiries, please reach us at support.dryice.ai@hcl.com