GBP Ranchi 2112

In release Ranchi 2112 of DRYiCE GBP on the ServiceNow platform, we have introduced new service requests for continual service improvement (CSIP) and availability management. Other highlights of this release include auto-population of ServiceNow CMDB tables with golden datasets output from ROAR and automatic reallocation of licenses to dormant users.

Agent Workspace

• The development work on the Agent Workspace app has progressed further with the introduction of a new capability under the incident category to configure ‘Form Headers’ with ‘Primary’ and ‘Secondary’ values, ‘Form Pane’ with ‘Form Section’s and ‘Fields’, ‘Related Items Menu’ with an item related to the records, and ‘Related List Actions’ with ‘New’, ‘Edit’ and ‘Add UI’ action. This will also include the capability to configure mandatory read-only fields on forms, form sections, and related lists based on incident status.  This will help fulfillers to collaborate and work on tickets and track their critical and assigned tasks in one place.

• Work on the Agent Workspace app has progressed further with the introduction of a new capability on ‘My Approvals’ in the ‘Self Service’ section to enable admins to configure ‘Form Headers’ with ‘Primary’ and ‘Secondary values, ‘Form Pane’ with ‘Form Section’s and ‘Fields’. The configurations will be compatible with the GBP functionality and will also include read-only, mandatory fields corresponding to different status values of approvals. This will help approvers to collaborate and work on tickets, and track all their critical and assigned tasks in one place.

• Work on the Agent Workspace app has progressed further with the configuration of ‘Ribbons’ on category forms displaying information such as timeline, user/customer summary, and SLAs. Also, now whenever new records are created or existing records are updated, the value displayed in the ‘Timeline’ field on ‘Ribbons’ will get updated simultaneously.

  This will provide fulfillers with a unified workspace to view, collaborate and work on the tickets and track all their critical and assigned tasks and capture timelines accurately.

• We have made further progress towards launching a unified workspace by mapping roles associated with ‘Modules’ and ‘Sub Modules’ on the Application Navigator to their corresponding ‘Categories’ and ‘Lists’ sections on the Agent Workspace application. This will ensure that roles and responsibilities configured on the Agent Workspace app are consistent with those in GBP.

Self Service Portal

• Now the version number displayed on the service portal footer will be automatically updated after the end of every sprint according to the latest release. This will ensure compliance with the product development cycle.

• Several changes and modifications have been made on the floating panel on the service portal to ensure uniformity in branding.

  • The bell icon notification on the right-hand side of the floating panel has been moved to the portal banner.

  • Now, upon publishing news and announcements the broadcast bell icon will be highlighted and the counter on the notifications section increased accordingly.

  • The icon representing the ‘Wish List’ link on the portal banner has been changed. Now, upon hovering on the ‘Tooltip/Helptext’ icon users will be able to see the number of items in their wish list.

  • The ‘My Service Status’ link has been removed from the portal banner.

  • Now, upon hovering over the Tooltip/Helptext icon on the shopping cart, users will be prompted with the message ‘Your shopping cart currently has X items’.

  • Now, upon clicking on the ‘KB Article Number’ under the ‘News’ tab, users will be automatically directed to the respective knowledge article.

  • The message ‘For a detailed description of News articles, kindly search with article no. in Knowledge Base at Home page’ displayed next to the ‘News’ tab’ has been removed.

  • The ‘Overall Survey’ list name under the ‘General Feedback Tab’ has been changed to "General Feedback Survey".

  • The title of the Survey form has been changed to General Feedback’. These modifications will help in enhancing the user experience.

Incident Management

We have made rapid progress towards introducing the ‘Swarming’ technique in the Incident Management module which has been listed below-

• Now, whenever there is a need for rapid resolution, incident assignees will be able to change the role of assignment groups to ‘Elevated Support’ by ticking the associated checkbox. On clicking on the checkbox, the Fast Track Support’ section will become visible with the following fields displayed: 

  a) Swarm Type

         b) Swarm Status

         c) Collaborative Resolution

         d) Swarm Lead

         e) Support Analysts

         f) Proposed Resolution Notes

         g) Annotation – Timelines

         h) Fast Track Start

        i) Fast Track End

        j) Time Remaining

This will help in managing the incident aging and incident hop count by quickly onboarding support members for collaboration which will lead to quick resolution of incidents.

• Upon moving the ‘Swarm Status’ to ‘Completed’, a ‘Reject Solution’ UI will become visible on the incident form. If the solution is rejected, the ‘Fast Track End’ field will be automatically emptied and the ‘Time Remaining’ field will be updated with the ‘Business Time Left’ for the resolution SLA. Upon changing the ‘Swarm Status’ to ‘Draft’ the ‘Support Analyst’ field will become editable, allowing swarm leads to enter details of the new members thus creating a new team.

  This will help in managing the incident aging and incident hop count by enabling different support members to collaborate on the same ticket paving the way for quicker resolution of incidents.

• Admin users will be able to create a property for enabling or disabling the swarming technique in the incident management process. Upon enabling the property, the ‘Elevated Support’ checkbox will become visible on the incident form allowing incident assignees to initiate the ‘Swarming’ technique. This swarming technique helps in rapid resolution by collaboration among incident support users.

• Now, upon clicking on the ‘Elevated Support’ checkbox on the incident form, incident assignees will be able to see the ‘Fast Track Support' form with the ‘Swarm Status' set to ‘Draft’. On selecting the appropriate group from the ‘Collaborative Resolution’ reference field and clicking on ‘Save’, the time of saving the details will be automatically populated in the ‘Fast Track Start’ field. Also, the ‘Time Remaining’ and ‘Swarm Lead’ fields will be auto-populated with the ‘Business Time Left’ of the resolution. SLA Swarm leads will be able to open the tickets after the tickets have been assigned to them and select team members in the ‘Support Analysts’ field, thus moving the ticket status to ‘In Progress’.

• Once the ‘Swarm Status’ has been moved to ‘In Progress’ and the appropriate support analysts have been assigned to the ticket, the mandatory ‘Proposed Resolution Notes’ section will become visible to swarm leads and support analysts. After filling the notes, the ‘Swarm Status’ will be changed to ‘Completed’ which will be time-stamped and displayed on the ‘Fast Track End’ field. The change in status will also be reflected in the list view as well as the form view.

  These will keep all the stakeholders informed on the completion of swarm activities.

• The following notifications will now be triggered upon changing the ‘Swarm Status’

  • Once incidents have been assigned to support analysts and the ‘Swarm Status’ updated to ‘In Progress’, notifications will be triggered to incident assignees, and copied to support analysts and swarm leads to inform them of the fast-tracked support.

  • Once resolutions have been provided by support analysts and the ‘Swarm Status’ changed to ‘Completed’, corresponding notifications will be triggered to incident assignees and copied to support analysts and swarm leads.

  • Now, whenever incident assignees click on ‘Reject Solution’ UI action moving ‘Swarm Status’ ‘Resolution Rejected’, notifications will be triggered to support analysts, swarm leads, and copied to the incident assignees.

These notifications will keep all stakeholders updated enabling them to act quickly based on the updated ‘Swarm’ status.

Service Request Management

• Now, upon navigating to request catalogs from ITIL view or support portal, users will be able to see a new category called ‘Create a new CSIP’ ticket, which will trigger approvals to related technical owners, service owners based on the CI selected. Once approvals have been granted, the associated catalog tasks will be triggered to their correct support groups for completion based on the improvement requirements captured on the ticket.

  This will help in setting up roles, groups to improve the organization’s processes and functions in an organized manner.

• Now, upon navigating to the service request catalog from ITIL view or support portal, users will be able to see a new category called ‘Create a new Availability’ ticket, which will be configured to trigger approvals to the related technical and service owners based on the CI selected. Once the approvals have been granted, the corresponding catalog tasks will be triggered to their correct support groups for completion based on the availability risks recorded in the ticket. This will help end-user request for the availability of service which was previously unavailable to them.

• Now, upon closure of CISP and Availability tasks, the status of associated RITMs and requests will be automatically changed to closed, and subsequently, notifications will be triggered to users who had opened the requests in the first place.

Patch Management

• Now, upon deploying patches through the patch workbench application, the status of the affected CIs will be automatically updated. Once updated, the users responsible for making patch changes will be able to view the updated status for each CIs. This will keep users updated on the status of the patch deployment.

• The label ‘Snow Computer Group ID’ has been changed to ‘PWB computer Group ID’ on the Computer Group table. Also, the application name has been changed from ‘Patch Workbench’ to ‘Patch Workbench (PWB)’.

• A dedicated ‘Patch Deployment Workflow’ has been introduced on the Patch Workbench application to be executed based on the values configured in the ‘Change Status’ and ‘Implementation Task’ fields on the properties page.

  The new workflow will be as follows –

  1. Create XML which will be filled with values defined in record producer and approved in related change.

  2. Trigger this XML to BigFix, where BigFix will ensure smooth execution of this XML.

  3. Upon execution of XML, responses will be received on the completion status of the job on each CI.

  4. Closure Information details to be updated based on the response received.

Once the XML is executed the patch deployment status on the CI table will be updated as follows:

1. Add the Patch and/or Patch Baseline Details deployed on CI.

2. Add the date & time when the patch was deployed.

3. Add the Change Ticket reference to the CI (already configured).

Once the activity has been completed, the status in the ‘Implementation task’ field will be updated based on the values defined on the Properties page.

• The ‘Create Patch Request form’ displayed upon selecting ‘Patch Change Request’ has been modified with the removal of the following fields –

  1. Urgency

  2. Category

  3. Subcategory

  4. Test Start Date (Under Schedule Section)

  5. Test End Date (Under Schedule Section)

• In addition to the above, the following values have also been detached from the form:

  1. Reason for Change

  2. CMDB update Required

  3. Details of CMDB Update

This will increase the efficiency of the patch deployment process as all the unnecessary fields have been removed.

• Now, after the patches missing in computer groups have been identified, patch admins will be able to configure rules for automating patch deployment from the ‘Configure Deployment Setting’ under ‘Patch Workbench’ on the properties page. The rules to be configured are given below –

  • Upon receiving CAB approval, the changing status under ‘Define what is the status of change after it is approved by CAB?’ will be changed to ‘Scheduled’.

  • Once ‘Scheduled’, patch admins will be able to configure rules for automatically changing the status under ‘Define what is the status of an implementation task when it is ready to be executed?’ to ‘Assigned’.

  • Once the patches have been deployed patch admins will be able to configure rules for automating the display of ‘Implementation task status’, ‘change request status’, ‘closure codes’ and ‘closure notes’ according to the following conditions –

    • When the patches have been successfully deployed for all CIs then ‘Implementation Task Status’, ‘Change Status’, and ‘Close Code’ will be displayed as ‘Closed Successful’, ‘Completed’, and ‘Successful’ respectively.
    • When the deployment is successful for some CIs only, then the ‘Implementation Task Status’, ‘Change Status’, and ‘Close Code’ will be displayed as ‘Closed Unsuccessful’, ‘Completed’, and ‘Partially Successful’.
    • When Deployment is failed for all Cis, then the ‘Implementation Task Status’, ‘Change Status’, and ‘Close Code’ will be displayed as ‘Closed Unsuccessful’, ‘Completed’, and ‘Unsuccessful’.
    • When Deployment could not be initiated due to ‘No Action ID (response) received to initiate the Implementation Task then the ‘Implementation Task Status’, ‘Change Status’, and ‘Close Code’ will be displayed as ‘Closed Unsuccessful’, ‘Completed’, and ‘Unsuccessful’.

This will help in automating the patch deployment cycle from initiation to completion of requests.

Now Mobile App

• Now, upon navigating to the ‘My Surveys Applet’ on the ‘Home’ page, end-users will be able to see and submit surveys triggered upon incident closure, post order fulfillment, and request fulfillment.

  This will provide users with the flexibility to submit surveys from the Now Mobile Application as well.

Communication Manager

• We have configured webhooks on our API for receiving inbound requests from Vonage. Upon responding to the message, a new record with a message ID will be created in the communication log for future evaluation. This will help in establishing a framework for a 2-way interactive communication for enabling inbound requests and auditing responses triggered by such requests.

iLicense

• A new field labeled as 'On-Hold Licenses' and a link 'On-Hold Users' have been introduced on the ‘Related Links’ section of the ‘License Count’ table to show unused licenses count and list of users who were unable to consume those licenses because of their inactivity or leave period.

  This will help the license managers to keep track of users whose inactivity days/leave periods fall within the license allocation period.

• Now upon checking on the 'Reallocation Required' field on the ‘License Role Mappings’ table, licenses will be automatically reallocated to dormant(inactive) users once they login after their defined inactivity days/leave period.

  This will reallocate roles automatically to such users whose inactivity days/leave period falls under the license allocation period.

Others

• ROAR GDS data received from Boomi and ServiceNow connectors will now be automatically populated into ServiceNow CMDB tables according to predefined mapping rules.

  This will save the time and effort of having to manually convert the GDS into the right format before populating it into the CMDB.

• Now, upon clicking on the ‘Import GDS’ page, users will be able to see a message “GDS Ready for Company’ specifying the ‘Company Name’, classes that were defined on the properties page, ‘Total Count’ of records processed and a link to import golden data sets (GDS). This will provide users with the flexibility to check the information contained in the report before proceeding with the download option.

• A new ‘Class Name’ field has been introduced below the ‘Company name in ROAR.’ field of the connector mapping table to include all the relevant class(es) for importing and exporting data to and from ROAR. This will allow admins to process data of all classes in one go rather than doing it class-wise.

• The names and order of the menu items in ‘ROAR Connector’ have been changed as below

         a) ‘ROAR’ will now be represented as ‘ROAR Connector’.

         b) ‘Onboarding Self-Help’ will now be represented as ‘Properties’.

         c) ‘Connect to ROAR’ will now be represented as ‘Test Connection’.

         d) ‘Mapping Classes’ will now be represented as ‘Fields Mapping’.

         e) ‘Import GDS’ will now be represented as ‘Update CI Records’.

         f) ‘Processed Records’ will now be represented as ‘Update History’.

• Now, upon receiving GDS output from ROAR, the status of each of the CIs will become visible, enabling users to ascertain the success or failure of the update based on the following validations –

  1. Are incoming values for an attribute to change as per the mapped values that need to be looked up in a database?

  2. Are incoming records or documents failing in checks of mandatory value should get stored in the rejected data store?

  3. Are incoming records or documents failing in checks of reference values looked up from a database should get stored in the rejected data store?

Upon rejection of data, the reason for its rejection will be recorded for future reference purposes. If the data is accepted, it will be used to update the CMDB based on hostname.

A new section has been introduced in ROAR App to allow users to see Processed Records until 7 days (Staging table).

For sales-related inquiries, please reach us at [email protected]

For Support related queries, please write to [email protected]