Hello!!!
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?
Change password
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.
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.
-
Corde Wagner
- Senior Itiler
- Posts: 60
- Joined: Fri Nov 10, 2006 7:00 pm
- Location: El Dorado Hills, California
- Contact:
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
ITIL 4 Managing Professional - ITIL v3 Expert - v2 Red Badge - VeriSM-Plus - Certified Agile Service Manager
-
Pra3torian
- Newbie
- Posts: 1
- Joined: Fri Oct 29, 2021 5:00 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.
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.