Locking down the short description

[Darren22]

Good morning all,

Looking for your opinions on a matter at hand. I have been asked to make the Short description on the incident form Read only once submitted. We have some teams that who like to add information to the short description and its been raised that this is data manipulation.
When trying to do some reading on best practice some people say you should actively change the SD so that its valuable and not just vague like "Windows general issue".

On face value it seems easy to lock down but I'm not sure sure. Also if we lock this field down then not even an Admin can amend it (Excluding background scripts) unless we put in some technical solution. 
It seems better that we should be educating our users more before trying to lock this field down.

Please can I have your opinion on this regardless of whether you agree or not. Have you had to do this and did you achieve it and if so how?

[Musab Rasheed]

Hi @Darren ,

It is always better to educate users not to change short description, Short description once entered should not be changed as per best practice. Also, there is no harm in making it read only and you can do it using UI policy as per best practice. In case you do not want short description to get updated even from background script or from integrations then you can make it read only from dictionary level but as per best practice it is advised to use UI policy to make fields read only. 

Regards

[Jaspal Singh]

Hi Darren,

In a way it is ideal to block or set the field to be read-only after submission as any update by any other user will be data manipulation.

Suggestion would be if needed an amendment you can it to be updated in Comments if user provides an update or Worknotes if they call helpdesk agents & then enhance it.

If needed, you can ask submit a request may be of type Operational Support or so that will come to admins to update it via some script or so. In this way you have a track of what is updated & on basis of which ticket in case of audit if any in future.

[umaaggarwal]

Hi Darren,

I have worked for more than 11 years in operations dealing with incidents and other kind of tickets. 

Off-course you can do it by ui policy/dictionary level etc but in real world teams get many incidents with meaning less short descriptions , so it is required by IT DESK or any other team to make the short description correct so that it can be picked up and worked upon by correct team and in correct manner.

So from my experience, I will not suggest to lock it, instead educate the users and also make a decision within team to have standard short descriptions for the known issues so that 2 members from the same team do not use different jargons for the same issue in the short description.

And I think manipulating the SD should not be a concern because the initial short description always remains in the activity logs. You can make sure that you update your activity logs to always show it and while educating the end users I would suggest take care of below 2 points : 

1. Educate them what to put in SD by giving different examples.

2. Inform them that if the SD does not make sense ( off course you can use fancy words so that users dont feel bad 😛 ) our teams might update the SD as part of process optimisation in order to deliver deliver better and timely results. 

Basically convince them that having meaningful SD will help them and us both. If they have reported multiple incidents, from the SD they can quickly identify what have they received an update for and same goes with the teams who work on the incidents. 

Hope it helps!

Thanks!

Uma