DRYiCE SX R10

This release of DRYiCE SX and GBP on SX includes new features like the capability to deflect incident tickets with contextual knowledge, provision to create incidents automatically from ticket details fetched from APIs, and the ability to auto-fill incident fields for VIP users. The other highlights of this release include the capability to cascade workarounds from problem tickets to associated incidents and enable existing users to auto-login into the knowledge center through the cloud directory.

Foundation

• The login page of multi-tenant instances has been enhanced to enable individual tenants to configure company logos according to their branding guidelines. This will enable users to create personalized home pages.

• A new feature has been introduced to automatically map user domains, extracted from email addresses used for creating users in foundation UI, to their respective App ID in cloud directory, thus saving time and effort on manually mapping each of them individually.

• The maximum number of characters permissible in the ‘Group Name’ field on Foundation UI has been limited to 30 characters, making it convenient for users to read the information quickly.

• The modules listed under the ‘Application Menu’ can now be sequenced in a predefined manner, providing users with a uniform view across all their organizational roles.

• Now, user records will be synced with ‘Cloud Directory/App ID’ only when the ‘Authentication type’ has been set to ‘Cloud Directory’ from ‘Foundation UI’.

• ’The ‘User Type’ field on the edit page has been made mandatory to make it consistent with the format on the ‘Create’ page.

• Now, while creating or updating user Ids from foundation UI, application administrators will also be able to use special characters. This will give them more options while creating user names.

Work Item Board

• The ‘SLA-Attributes’ and ‘Edit Incident’ fields on the incident form have been modified with the removal of the value ‘Critical’ from their respective priority dropdown lists. Once incidents have been accepted as ‘Critical’, the status will be displayed as the read-only value on the edit incident form.

• A new ‘Company’ field has been introduced on problem/change work item edit pages providing visibility of the company associated with the records, thus reducing the probability of editing records by mistake.

SLA Board

• The SLA board has been enhanced with the inclusion of additional columns such as 'Name', 'Consumer company', 'Target for', 'Status' and 'Module' and the capability to filter the list of SLAs based on 'Company', 'Target for', 'Status' and 'Module'. This will make it convenient for users to search for information quickly.

• The SLA form has been modified to include fields 'Name, 'Consumer Company', 'Module', 'Status', 'Target for'. 'Target time', 'Type', 'Work schedule', and 'Holiday schedule'. This will make it easier to configure and track SLAs efficiently.

• Now, upon clicking on ‘Add New Milestone’, a dropdown list will become visible with milestone values of ‘50’ and ‘75’ respectively. The threshold value of ‘100’ has been replaced with the value ‘Breach’ to configure SLA breaches.

• Now, upon retroactive increase/decrease in priority, the SLAs associated with incidents with updated priority will become applicable from the new timestamps.

• A new capability has been introduced on the SLA board to configure SLAs based on additional attributes including 'Status', 'Assignment group', 'Priority', 'Service', 'Class', 'CI' and 'Requester'. Similarly, SLA rules will be able to incorporate 'And' and 'Or' operators between attribute values, thus covering all possible use cases.

• Now, whenever the SLAs for fulfillment, incident, problem, and change requests are breached or cross their threshold, notifications will be automatically triggered to configured recipients. This will alert the recipients promptly, enabling them to act appropriately.

Consumer Portal

• The typeahead search box has been configured to trigger search API only if the input value qualifies the criteria set for minimum character length. This will prompt users to enter an adequate number of characters, thus improving their user experience.

• A new ‘Incident Deflection’ capability has been introduced on the ‘Order now’ page to trigger a knowledge search based on the keywords typed on the incident description field. This will enable users to find their answers based on knowledge articles without seeking support.

• Now, while using the Data Queries section, attributes like ‘Ticket No./Work Item ID’, ‘Requester’, ‘Service Name’, ‘CI Name’, ‘Status’, etc will be auto-selected by default to ensure that all the key information has been generated in the report.

Fulfillment

• Now, in the case of users with multiple fulfiller roles, the Field-Status mapping will be based on the role providing the highest privileges.

• Now, reopened service requests will be automatically assigned to their associated groups allowing any group member to take responsibility for the work. This will reduce the number of unattended tickets due to the unavailability of individuals assigned to tickets.

Incident and Problem Management

• Now, change requests can be proposed from incidents or problems only after they have been linked to the CIs that have been impacted, reducing implementation failure due to conflicting CIs.

• Now, incident/problem users and managers will not be able to create or update requests on ‘Work Item Board’ for Assets/CIs unless they have been 'Deployed', thus removing inaccuracies in data.

Incident Management

• Now, in the case of users with multiple incident management roles, the Field-Status mapping will be based on the role providing higher privileges.

• Now, upon submitting/copying incidents for VIP users through the portal/work item board/ service desk, the fields ‘Impact’ and ‘Urgency’ on the incident form will get auto-populated with ‘Moderate’ and ‘High’ values respectively. This will ensure the availability of prioritized support to VIP users even if the details have been incorrectly filled.

• The Critical Incident Review (CIR) process has been introduced such that a critical incident manager will need to manually close a critical incident by submitting a CIR form.

• The subject line and email-body of the following out of the box incident notifications have been modified

  • Incident notification for ‘Re-open (Work Item)’ triggered to the impacted users;
  • Incident notification for ‘Feedback Request (Work Item)’ triggered to the impacted users;
  • Incident notification for ‘Re-open (Work Item)’ triggered to the assigned support group;
  • Incident notification for ‘Closed (Service Request) triggered to the assigned support group;

  This will enable the notification recipients to understand the essence of the message quickly, enabling them to respond quickly if required.

Problem Management

• Now, the workarounds for known errors that have been logged into the ‘Activity Journal’ will be automatically displayed on all incidents associated with the problem. This will help to release information on workarounds in the entire organization, improving user satisfaction and the overall efficiency of the IT department.

Change and Problem Management

• The 'Service/CI' column displayed on the change and problem modules of 'Work Item Board' has been relabelled as 'CI' since the change and problem tickets will only be allowed to be raised for impacted CIs.

Change Management

• Now, a ‘Replan’ activity will be allowed to proceed further only if the identity of the logged-in users matches that of an ‘Implementation Individual’, ‘Change Individual’, or ‘Requestor’. This will introduce checks and balances for preventing unauthorized changes.

• Now, upon moving the status of change requests from ‘Under Implementation’ to ‘End Implementation’ without closing associated tasks, a pop-up will become visible with the message ‘User is not able to end the implementation, if any of the associated tasks is not completed.’ This will ensure the efficiency of the change management process.

• Now, the change risk computed on the ‘Risk Assessment’ form while submitting change requests will also be displayed as a read-only value on the ‘Overall Risk’ field of the ‘Change Request Edit’ form. This will help to understand the risks associated with change requests before making edits on them.

Approval

• The content of the following notification has been improved to make it easier for its recipients to respond to changes of status once alerted

  • Notifications sent to delegators to inform them of the delegated approvals;
  • Notifications sent to delegators that their delegation is about to expire;
  • Notifications sent to delegators to inform them of the expiry of the delegation period;

  This will enable the notification recipients to understand the essence of the message quickly, enabling them to respond quickly if required.

• The default undertaking message displayed on the Approval page for all approval requests has been removed as it can be directly added in the Service/Approval disclaimer of that service.

Task Board

• The validation message ‘Information is too short’ displayed on incident, fulfillment, problem, change request forms while creating ad-hoc tasks and on the ‘Summary’ and ‘Additional Information’ fields on the edit task form has been removed.

• Now, upon creating ad-hoc tasks or fulfillment plans from incident/problem/change modules, the CI/service names associated with such tasks will be captured for display in the task listing page and task details panel.

• A new ‘SLA-in-Progress’ icon has been introduced on the edit pages of ‘Task Module’ to provide summarized information of all SLAs, enabling fulfillers to take any appropriate action if needed.

• The ID of the Parent Work Item displayed on the breadcrumb’s widget has been hyperlinked to enable navigation to the relevant incident record from the edit task form.

• Now, while editing tasks on the TMS edit page, support managers will be able to click on the ‘Show All Groups’ link to see all groups for their companies as well as associated companies that were configured on the foundation UI. This will provide quick access to the information required to complete tasks.

• A new 'Task Status' field has been introduced on the data queries section of the 'Report Console' to show the current status of tasks.

• The ‘Service/CI’ text box on the ‘TMS Board’ has been split into read-only ‘Service’ and ‘Impacted CI’ text boxes for more clarity.

• The ‘Work Schedule’ and ‘Target Definition’ UI has been enhanced with the introduction of filter and search capability under each of the column headers listed on the page. This will provide users with the flexibility to create search conditions based on a ‘text’, or a ‘date range’ filter or combine all the filter values for a custom search.

Asset and Config Board

• Now, assets/CIs will not be deployable unless they have been associated by asset/config managers to their respective chain entities on the incident, problem, and change modules. The introduction of chain entities on the CMDB Board will automate the process of creating additional AMS rules.

• A new capability has been introduced on the CMDB Board to allow asset/config managers to introduce ‘Chain Entities’ for problem tickets. Once this has been configured, AMS rules will get configured in the AMS board for problem tickets.

Incident and Knowledge

• Now, upon clicking on ‘Relate Knowledge Articles’ on the incident form, fulfillers will be able to see all KB and Crowdsourced articles based on the information provided in the ‘Issue Description’ field. This will provide fulfillers with the flexibility to choose articles contributed by the community or generated by the system.

Knowledge

• The introduction of SSO for Cloud Directory has been enabled on the Knowledge Center Widget to enable users with activated Insided accounts to auto-login into the application instead of landing on the login page. This will provide secure access to existing users without having to enter their credentials manually.

Notifications

• The following OOB notifications configured in the fulfillment module have been revisited and rephrased in terms of subject line and body. Also, some additional fields have been added to the body to give appropriate information to recipients -

  • Notifications triggered to consumers upon logging of service requests;
  • Notifications triggered to consumers upon logging of service requests on their behalf;
  • Notifications triggered to approvers on service requests pending for their approval;
  • Reminder for requests pending approval;
  • Notifications triggered to consumers upon approval of service requests;
  • Notifications triggered to consumers upon rejection of approval requests;
  • Notifications triggered upon cancellation of service requests;
  • Notifications triggered to fulfillment team upon cancellation of service requests;
  • Notifications triggered to consumers to inform them the service requests are under fulfillment;
  • Notifications triggered to the team to inform them on the assignation of requests for fulfillment;
  • Notifications triggered to the team to inform them that the configured SLA has been breached;
  • Notifications triggered to the team to inform them the milestone configured for the work item has elapsed;
  • Notifications triggered to consumers to inform them that the expected completion date of their service request has been updated by the fulfiller;
  • Notifications triggered to customers to inform them on their service requests put on hold;
  • Notifications triggered to team to update them on service requests put on hold;
  • Notifications triggered to consumers asking for their feedback on fulfilled requests;
  • Notifications to the team to inform them of the successful fulfillment of requests and feedback triggered to consumers;
  • Notifications triggered to consumers reminding them of the pending feedback;
  • Notifications triggered to consumers to inform them of the closure of requests;
  • Notifications triggered to team to inform them on the closure of requests;

  This will enable the notification recipients to understand the essence of the message quickly, enabling them to respond quickly if required.

• The subject line and email body of out-of-the-box notification templates configured for incidents and tasks have been modified based on inputs received. This will help in making the notifications intuitive and easy to understand.

• Now, upon logging incidents for the very first time, incident notifications will be sent to assigned support groups. This will allow them to take timely action, thus avoiding SLA breaches.

• Now, if the details of assignee individual/managers are unavailable, notifications will be automatically triggered to ‘Assignee Groups’ upon SLA breach/milestone preventing delay in response due to non-delivery.

• The out-of-box notification templates configured for change/problem/task/approvals have been enhanced making it easier for the recipients to understand the message and act promptly upon it.

• Now, upon failing to deliver email notifications due to known errors, the retry logic built into the notification engine will automatically trigger the emails to the recipients after the expiry of a specified period.

• The subject line and email-body of the following Change notifications have been modified –

  • Notifications triggered to delegatee informing them that they have been appointed as ‘Alternate delegator’ by the delegator;
  • Notification triggered to ‘delegator for’ informing them that the delegation to the ‘delegatee’ is about to expiry’;
  • Notification triggered to ‘delegator for’ informing them that the delegation period has expired;

  This will enable the notification recipients to understand the essence of the message quickly, enabling them to respond quickly if required.

• Now, upon canceling fulfillment requests, notifications will be triggered to requesters as well as to assigned support groups. This will alert stakeholders about the change in status, enabling them to act promptly.

• The subject line and email body of the following notifications have been updated –

  • Notifications triggered to requestors and assigned team informing them on the identification of corrective actions as part of the root cause analysis;
  • Notifications triggered to requestors and team informing them that the status of problem requests has been changed to ‘Corrected’;
  • Notifications triggered to requestors and assigned team informing them that the status of problem requests has been changed to ‘Closed’;

  This will allow notification recipients to understand the essence of the message quickly, enabling them to respond quickly if required.

SPCM

• Now, while editing the selected services for Standard change on the service board, the sections for configuring fulfillment plans and approvals will no longer be visible to catalog managers. This will enable catalog managers to configure pre-approved, documented, and repeatable workflows for standard changes from the asset/config board.

• Now, while creating support chain entities for incident-based offerings, catalog managers will be able to choose ‘Resolver’ or ‘Critical Incident Manager’ from the ‘Assignment For’ drop-down menu. This will allow catalog managers to configure AMS rules easily.

All Processes

• Now, whenever comments are posted on the ‘Activity Journal’, the ‘Internal’ checkbox will be automatically ticked by defaults. This will ensure visibility to only those fulfillers/incidents users/managers who are working on those tickets or have permission to view them.

• APIs have been introduced for fetching ticket details on open incidents for Systrack - Lucy - SX integration. Once the details have been retrieved, backend APIs on Lucy will be used to create incidents. This will help to automate the incident management process improving MTTR thus improving customer satisfaction.

• A new ‘Company’ field has been added on the work item edit pages of incident and fulfillment requests to enable fulfillers to differentiate services raised in a multi-tenant environment.

• The ‘ previous status’ and ‘ previous group’ fields will now be included in APIs passed to SX-Hub to enable middleware tools to invoke the correct systems based on changes in the status of the configured fields since the last update.

DRYiCE SX™ accelerates service delivery by seamlessly aggregating catalogs creating a single system of engagement. DRYiCE GBP SX™ offers true enterprise service management by unifying IT and non-IT services on a single catalog.

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