Change password

An open discussion on issues related directly or primarily to the service or help desk.
Post Reply
Posts: 2
Joined: Fri Jun 28, 2019 11:38 am

Fri Aug 30, 2019 1:06 pm


The user open a ticket on ServiceDesk informing that a him forgot a password, and request a password change

To user, is a impact because the login on network is innoperant.
But the user know that he forgot password

This is a incident ou service request?

Senior Itiler
Senior Itiler
Posts: 31
Joined: Fri Apr 05, 2019 10:25 am

Sun Sep 08, 2019 9:14 am

Yes. Or yes. It is whatever you define it to be. :-)

In most organizations, this is defined as a service request, because it is highly likely that users will forget passwords, and it is usually a simple operation that can be pre-defined (even automated?) for resetting a password. While it is a interruption to normal service per se, it is an interruption only to a single user. The target system is still available and running in an operational state.

However, there may be a reason to define this as an incident. For example, if a network administrator cannot log-in to a network device in a secured environment/DMZ. Has the security/integrity of the device been compromised? Or is it a case of the administrator simply forgetting the password?

Personally, I'd always treat these as service requests until I had a good business reason not to.
User avatar
Corde Wagner
Senior Itiler
Senior Itiler
Posts: 60
Joined: Fri Nov 10, 2006 7:00 pm
Location: El Dorado Hills, California

Wed Sep 11, 2019 4:30 pm

I agree with Ted that a password resets can be recorded as either an incident or request, but the rational for either should be clearly documented to reduce confusion. From my point of view, I would always treat requests to reset a password as service requests.
Corde Wagner
ITIL 4 Managing Professional - ITIL v3 Expert - v2 Red Badge - VeriSM-Plus - Certified Agile Service Manager
Posts: 13
Joined: Mon May 20, 2019 3:58 am

Thu Oct 03, 2019 11:57 am

To me this is a no-brainer-->SR all life long. :D
Posts: 1
Joined: Fri Oct 29, 2021 5:00 am

Fri Oct 29, 2021 5:21 am

So I realize this conversation is a little old, but I have a new perspective on this topic.

When the user calls, and says they need their password reset, what they're really saying is "I cant log into my machine. I could yesterday, or last Friday, but today I cant." The need to reset the password, is the solution / resolution code. The inability to log in, is a break fix. Where else doe we allow the fact that the user knows what needs to happen to restore service, dictate which side of the isle this lands within the ITSM architecture?

For example, a Program is connected to a database, which is configured to lock, if someone else is in the record, or if they log off improperly (user error preventing access to functionality). If the user calls and says "can you please unlock record XYZ in the database again? Judy forgot to get out of it when she left yesterday." Do we turn that into a "request to unlock database record" ? Both are previously available functionality. Both occur as the result of a user error triggering a condition where the user experiences an un planned interruption.

Another example. a user has a network share, which they accidentally delete. They contact the desk, "can you please restore my network share? I deleted it." Is this a request, because the user knows they need their file restored as a means of resolution?

So that's where I stand. The interruption in access to the account is an incident, and the password reset, is the resolution.

Additionally, I find that most people who want to put this in the request task type, do so because of the impact of the volume of the tasks, rather than the nature of the task, at which point they retroactively use any logic available to justify putting it in the other side of the isle.
Post Reply