SummitAI Tahoe SP1 Release Notes
Download Release Notes | Previous Versions: << Sierra << Sierra HF01 << Sierra SP1 << Sierra SP1 HF01 << Sierra SP1 HF02 << Sierra SP1 HF03 << Denali << Denali HF01 << Denali HF02 << Denali HF03 << Denali SP1 << Denali SP1 HF01 << Tahoe
On this page:
What's New?
Highlights
The following links provide Module-wise summary of key features introduced in Tahoe SP1 Release.
Platform
License Expiry Notification
Enables an administrator to configure the license expiry notification, send notifications to desired set of selected users, and set the expiry reminder to alert the user(s) about the license expiry.
Offboarding User Policy
Provision an analyst to address pending and progressive dependent items (Incident, Service Request, Change Request, and Problem Record List) associated with the offboarded analyst.
An Offboarded Users link to list the dependent records associated with offboarded user account specific to the configured Domain, Tenant, and Workgroup.
API Discovery
To discover multiple type of devices, SummitAI now offers API based discovery. Based on the API configuration, the Servers, Networks, Links, Printers, and Laptop devices in the organization can be identified or define to establish connection with the configured APIs.
Service Management
Business Rule Designer
Schedulers are introduced in Business Rule Designer that enables you to schedule incidents for automating different tasks such as Updating Fields, Sending Notifications in a scheduler manner. Few examples of this could be auto resolving incidents that are pending since more than 2 months, sending notifications to Workgroup Owner if a VIP ticket is left unattended for more than 3 hours, or auto-cancel old incidents. This way, all the low value activities traditionally done by technicians can be offloaded to Business Rule Designer, thereby enabling the technicians to focus on high value activities.
Incident Closing Mode is introduced in Business Rule Designer that enable you to close the incidents automatically or manually as per business requirements. Automation of incident closure helps the Administrator to define the closure mode based on the variety of criteria. The key piece to this auto closure feature is the ability to automatically close the incidents based on the following:
Business Days - Business days will not include Holidays and Weekends
Calendar Days - Calendar days will include Holidays and Weekends
Call Management
When a Call is resolved, the technicians are now prompted to select the Closure Code. Consequently, the technicians can update the Closure Code as Successful, Unsuccessful, Deferred etc. As a result, the Service Desk can build visibility with Reports that help them to objectively measure the service quality and also identify and execute opportunities that enhance Customer Satisfaction (CSAT), as a part of continual service improvement.
Introduced a list of relevant Knowledge Articles as recommended solution when the Analyst is typing in the user’s query in the Call Record. This enables the Analysts to instantly resolve the user’s queries, thereby improving the overall customer experience. Hence, we have integrated Knowledge Management and Call Management.
Change Management
You can now set rules that would automatically close the Implemented Change Requests after a specific period. Defining the Closure Mode (Auto / Manual) is important because it -
Eliminates the need for technicians to manually close the Change Requests
Enables the Service Desk to operationalize the business process laid out by the organization
Eliminates any potential human errors - miss out closure of CRs etc.
Better control over Notifications can now be established by configuring when the Analysts should receive the notifications during the life cycle of the Change Request. Administrators can decide if the Analysts should be notified after every Approval or Update or should be notified only after the CR is assigned to them.
Problem Management
Operational Level Agreements can now be defined for the Work Orders created from Problem Records, similar to Incident and Service Requests. As a result, it ensures that the internal SLAs between teams are met and thereby ensure on-time delivery of service. OLAs act as a foundation of good practise and common agreement.
The Approvers can now approve, review or reject the Problem Records directly over email. The details of the Problem Record can be embedded in the email, thereby eliminating the need for Approvers to traverse back and forth between mail and SummitAI Web Application for approvals.
You can now customize the Work Order Forms of Problem Record by adding custom attributes defined at the Problem Record level. This allows the Analysts to capture the details at the Work Order level by filling in the custom attributes, thereby enabling better tracking.
Service Request
Introduced a restriction to prohibit the Requestor to select the same user as an Approver for User Group Approval in SR workflow, while configuring Service Request at Tenant level. Hence, enhanced the approval process by restricting the Requestor as one of the Approver. Hence, it will be helpful to avoid misuse or manipulation of the authorized access.
For example, User1 is the Requestor and User Group Approval group comprises of User1, User2 and User3. This feature prohibits the User1 to select User1 (self) as approver.
Database Schema DN Tables
The following new DN tables are added for Service Management in SummitAI Service Management Database Schema Definition Guide.
DN table are now developed to capture the checklist parameters such as Checklist Name, Status, Updated By – This can be used to build Reports that would help provide visibility on how the checklists are updated by Analysts for Incident Management module. (IM_RPT_DN_Change_Checklist_History)
DN table are now developed to capture the checklist parameters such as Checklist Name, Status, Updated By – This can be used to build Reports that would help provide visibility on how the checklists are updated by Analysts for Service Request module. (SR_RPT_DN_Change_Checklist_History)
DN table are now developed to capture the checklist parameters such as Checklist Name, Status, Updated By – This can be used to build Reports that would help provide visibility on how the checklists are updated by Analysts for Change Management module. (CM_RPT_DN_Change_Checklist_History)
DN table are now developed to capture the catalogs parameters such as Catalog Response SLA, Catalog ID, Catalog Response Business Days – This can be used to build Reports that would help provide visibility on how the Service Catalogs are updated by Analysts. It holds all the detail about the Service Catalogs. (SR_RPT_DN_ServiceCatalog_Master)
Asset Management
Add Software screen is improvised to facilitate simplified configuration of the Software Inventory and License Management Modules.
Asset return process is enriched to enables best-in-class asset tracking mechanism.
New provision to an Administrator for the custom Sub Status configuration of Fixed and Non-fixed assets.
IT Operations Management
Service Dashboard
Service Dashboard helps the Analyst or Admin to monitor all the details about the available services. This dashboard provides complete information about the service and its components.
Support for API related to monitoring Meraki devices
A new feature is added to monitor Meraki devices in the Discovery using API as a Monitoring Protocol. This enables the Admin to monitor the Meraki devices in the Discovery.
New Features
Platform
Feature Name | Feature Description | Feature Benefit |
License Expiry Notification Target Persona: Admin | The License Expiry Notification feature helps to configure the license expiry notification and send notifications to desired set of configured users. Using this functionality, an admin can set the expiry reminder to alert the user(s) about the license expiry. The UI using the ‘Set License Expiry Reminder’, instead of the Web.config file. For more information, see License Expiry Notification. |
|
Offboarding User Policy List Target Persona: Analyst | The Offboarding User Policy List feature enables in addressing the pending and progressive dependent items associated with the offboarding analyst. A new tracking incident is created, and e-mail notification is triggered to respective stakeholders about the dependents of offboarding user accounts. For more information, see Offboarding User Policy. This feature enables to:
A new Offboarded User link is implemented to view the list of dependent records associated with offboarding user account specific to the selected Domain, Tenant, and Workgroup. Note: The records are accessible, if the logged in user has analyst privileges and associated with the respective workgroup. Else, the records appear greyed out. |
|
API Configuration Target Persona: Administrator | To discover multiple type of devices, SummitAI now offers API based discovery. Based on the API configuration, the Servers, Networks, Links, Printers, and Laptop devices in the organization can be identified or define to establish connection with the configured APIs. It identifies or supports all the devices wherever an APIs is required. Using API configuration, you can:
For more information, see API Configuration. |
|
Service Management
Feature Name | Feature Description | Feature Benefits |
|---|---|---|
Incident Closing Mode at Business Rule Designer level Target Persona: Admin | On a Business Rule page (Admin > Basic > Infrastructure > Business Rule > UPDATE FIELDS), a new drop-down box Incident Closing Mode is introduced with two new options Auto and Manual. On a Business Rule page, a new text box Auto Closing days is introduced. This text box is enabled if Incident Closing mode is selected as Auto. It will also have the drop-down with the following Business Days and Calendar Days options. For more information, refer to Business Rule Designer. At Tenant configuration level for Incident module, a new drop down is introduced along with text box for Auto Closing Days. This drop-down will have the Business Days and Calendar Days options. Note:
For more information, refer to Configuring Incident Management Module. Note: Incident Closing Mode configuration done at Business Rule Designer will override the incident closure configuration done at Tenant, Category and Workgroup level. For more information, refer to Configuring Category, Configuring Workgroups. |
|
Configuring a Schedule in Business Rule Designer Target Persona: Admin | A new check box Schedule is added for Trigger Type on the BUSINESS RULE page. New filter Trigger Type is added under FILTERS with the following options:
Schedule Info icon is introduced which will be displayed along with Business Rule ID in SHOW LIST under ACTIONS. For more information, refer to Business Rule Designer. |
|
Bar Caller from the Approver List Target Persona: Admin | A new check box Bar Caller from Approver List is added on the TENANT page (Admin > Basic > Infrastructure > Tenant), under the For Approver section for Service Request. For more information, refer to Configuring SR Management. If Enable Approver Selection under CONFIGURE USER GROUP is disabled then in case of multiple approvers, this feature will remove the caller from the approver list after submission. If the caller is the only approver, then system displays a validation message and blocks the SR submission. If Enable Approver Selection under CONFIGURE USER GROUP is enabled then in case of multiple approvers, if user selects only caller as an approver, system displays a validation message and blocks the SR submission. If user selects multiple approvers including a caller, this feature will remove caller from the approver list once the SR gets submitted. If the caller is the only approver then system displays a validation message and blocks the SR submission. |
|
Auto Close Change Request Target Persona: Admin | On the TENANT page (Admin > Basic > Infrastructure > Tenant), a new sub-section CHANGE REQUEST CLOSURE is added under DETAILS section for Change Management module with the following new configurations:
For more information about how to configure CHANGE REQUEST CLOSURE for the automatically or manually, refer Configuring Change Management Module. |
|
Manage CR Approval, Update, and Task Notifications in Change Management | Administrator can manage the CR Approval, CR Update, and Task notifications triggering to the workgroup members while creating the workflow by selecting the following fields. On the PROPERTIES pop-up (Approval), the following fields are added newly.
On the PROPERTIES pop-up (Task), the following field is added newly.
For configuration, see Configuring CR Approval Workflow. | Better control over the notifications – Make sure the right notifications are sent to the right stakeholders at the right time. |
Creating, Viewing and Updating a Work Order for a PR Target Persona: Admin | You can configure the Operation Level Specifications (OLS) for Problem Management also under the DEADLINE tab on NEW OPERATIONAL LEVEL SPECIFICATIONS like Incident Management and Service Requests. For more information, refer to Operation Level Agreement (OLA). Analyst can create, view and update the Work Orders. For more information, refer to Creating Work Orders, Viewing and Updating Work Orders. |
|
Problem Record (PR) approval via e-mail Target Persona: Analyst | For every Problem Record (PR), the Approver can quickly do one click approval from email. Configuration An Analyst needs to select Enable PR Approval by E-mail check box under the APPROVE tab on the CONFIGURE PARSING CONDITIONS section on the NOTIFICATION PARSER page. *APPROVAL_TABLE* and *APPROVERACTIONS* are added in the template Authorization, RCA Approval and RCA review template to display the PR details in the PR approval e-mail notification. For more information, refer to Approving Problem Record via E-mail. |
|
Knowledge Articles Recommendation in New Call Record for User Page | The Analyst can use the Knowledge Records (KRs) to provide solutions to the End Users and avoid logging new Incidents, Service Requests, or Enquiries. For more information, see Creating Call Records. A list of Knowledge Records relevant to the entered subject will display in the Recommended Solution(s) Found pop-up, as you start typing in the Subject field on the NEW CALL RECORD FOR USER page (Call > User > Manage Calls > New Call Record for User), Various sections of the KNOWLEDGE RECORD DETAILS page:
If a knowledge article is a Public Article, the above fields will not be displayed. For more information about the public article, see Creating Call Records. |
|
Closure Code for Call Management | A new field Closure Code is introduced on the NEW CALL RECORD FOR USER page (Call > User > Manage Calls > New Call Record for User). Also, while closing an Enquiry call record or creating/submitting an Incident or Service Request call record, the analyst needs to select a Closure Code. Closure Code for Enquiry Call record Earlier, the Solution and Private log fields were displayed when an Analyst changed the Information or Enquiry call record status as Closed. When the Analyst selects the Information or Enquiry call record status as Closed, the following fields are displayed.
Closure Code for Incident/ Service Request Call Record While submitting an Incident or Service Request call record, the analyst needs to select a Closure Code. The selected Closure Code will be tagged to the call record only if the call record is successfully converted to an Incident or Service Request. Enable Closure Code Menu How to enable closure code sub menu, see Configuring Closure Codes. Using this menu, the admin can configure Closure Codes based on the organizational needs. The Closure Codes defined by you are available to the Analysts while closing enquiry call records or while creating/submitting an Incidents or Service Requests call record. For more information about how to configure closure codes, see Configuring Closure Codes. |
|
Use Problem Management Custom Attributes in the PM Work Orders |