Ivanti Service Manager HEAT Incident Customer History Quick Action UI Action

How to show Customer History using Quick Action

One of the HEAT Classic Features that is frequently requested is to bring back the customer history. There are several implementations for this, yesterday covered how to implement Incident Customer History for Related Items, aka Object Matching, today we will cover how to show Customer History using a Quick Action.

  1. Create a UI Quick Action for Incident
  2. Scope: ObjectWorkspace
  3. Command ID: Search
  4. Confirmation: null
  5. Command Data:

‘ObjectType’:’Incident#’,
‘SearchCriteria’:[
{‘ObjectId’:’Incident#’,’FieldName’:’ProfileLink_RecID’,
‘Condition’:’=’, ‘FieldValue’:’$(ProfileLink_RecID)’}
],
‘FillSearchPanel’:’true’

Save and add to the Incident Layout Form View Toolbar with disabled expression:
$(nvl(ProfileLink_RecID, “”) == “”)

One of the HEAT Classic Features that is frequently requested is to bring back the customer history. There are several implementations for this, today we will cover how to implement Incident Customer History for Related Items, aka Object Matching.

How to show Customer History in Related Items (Object Matching)

One of the HEAT Classic Features that is frequently requested is to bring back the customer history. There are several implementations for this, today we will cover how to implement Incident Customer History for Related Items, aka Object Matching.

  1. Open the Incident Layout you wish to implement this for
  2. Open the Form View
  3. Click “Edit Matching Settings
  4. Edit the Existing Incident Object
  5. Click Edit Filter
  6. Edit the “Resolved Filter” and change it to “Resolved + Customer History
    Note that you could add a new filter but then the user has to select that filter manually or disable
  7. set Condition to $([MatchedObject]Status == “Resolved” OR [MatchedObject]ProfileLink_RecID==ProfileLink_RecID)
  8. Save all your changes
  9. Refresh your Browser
  10. Test your Changes
  11. Like my Blog and tell all your friends!
One of the HEAT Classic Features that is frequently requested is to bring back the customer history. There are several implementations for this, today we will cover how to implement Incident Customer History for Related Items, aka Object Matching.

Tips & Best Practices:

You can add additional filters or edit existing filters to show:

  • Master Incidents
  • Incidents from Employees with the same Org Unit, Department, Location
  • Incidents that are Logged or Not Closed (where you want to see what similar Incidents are out there that haven’t been Resolved/Closed

Waiting for Resolution Incident Status

A very frequently asked question when implementing Ivanti Service Manager (HEAT) evolves around the “Waiting for Resolution” Incident Status. What is its significance, should it be used, and how does it effect SLAs?

The “Waiting for Resolution” Status is typically used when a break/fix (Incident) has been completed but the ticket hasn’t been updated yet.

For example if there is a P1 Incident that has been resolved, setting the Status to “Waiting for Resolution” may prove to be rather useful to stop the SLA clock while gathering all incident resolution details from the SDAs and Task Owners, without getting penalized.

Remember that the SLA Clock is driven by the Incident Status and Waiting for Resolution pauses the SLA clock.