Password Resets. Incident or Service Request?

Can Password Resets even be logged by a user? Of course!

1. There are many passwords besides your Single Sign-On (SSO) password.
2. Self Service can be configured to allow anonymous Incidents and Service Requests.
3. You could always ask a colleague to log a ticket for you.
4. You could just pick up the phone and use the Interactive Voice Response (IVR) System, Ivanti Voice to submit a password reset.
5. You could just pick up the phone and call the Service Desk who then logs the Ticket.

Of course there are those famous hostage and drive-by situations (my favorite Source codes), but I won’t count those. And here you were about to laugh out loud proclaiming you can’t log a ticket without a password. Not mentioning any names. You know who you are. Shout out to my friend in Australia 😉

Now that we have that out of the way….

Incidents (Break/Fix) and Service Requests (New/Change to Service) are often long debated by companies new to ITSM (IT Service Management).Password Reset Requests do not make the differentiation any easier.  Are they a break/fix or service request?

The subject actually goes much deeper as Incidents are viewed negatively.  More incidents, more issues, higher IT instability.  While Service Requests are positively viewed as a demand for IT services.

Password Resets – Incident or Service Request? (Re-recorded Sep 24) – Independent ITSM Podcast covering Ivanti Service Manager ISM HEAT Latest Solutions & Best Practices

Incidents (Break/Fix) and Service Requests (New/Change to Service) are often long debated by companies new to ITSM (IT Service Management). Password Reset Requests do not make the differentiation any easier.  Are they a break/fix or service request?    Can Password Resets even be logged by a user?   Of course! There are many passwords besides your Single Sign-On (SSO) password. Self Service can be configured to allow anonymous Incidents and Service Requests. You could always ask a colleague to log a ticket for you. You could just pick up the phone and use the Interactive Response System (IVR), Ivanti Voice to submit a password reset. You could just pick up the phone and call the Service Desk who then logs the Ticket.   The subject actually goes much deeper as Incidents are viewed negatively.  More incidents, more issues, higher IT instability.  While Service Requests are positively viewed as a demand for IT services. Do you have an Ivanti Podcast Topic or Question?  Submit it at podcast.a19consulting.com

Advertisement

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, “”) == “”)

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!

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.