Set state field to read only for a new Incident

[StewartF]

So, we've noticed an issue where, when creating an incident, if the state field is changed before the form is submitted/saved, the SLA timer doesn't actually start. Meaning we have had P2's technically breach the SLA, but reporting shows that it's actually made the SLA.

I've narrowed this down to ITIL users changing the state field to Active before the form is saved.

What I want to try and do it set 'state' to read only until the form has actually been submitted. Once it has, it can then be editable again.

I believe this would be best as a UI Policy rather than a Client Script?

Due to not being very clued up on scripting yet, I've been trying the standard way of setting fields, but nothing is working. Would anybody know the right script to use to make it work?

Any help would be greatly appreciated!

[Wuang]

Hello @straut 

I struggled with this issue before and I solved it by using a UI Policy. 

If you set the conditions to Created By - is empty and set the UI Action with the State field to read-only = true. Once the ITIL users create a new incident, the State field should be read-only. This will prevent them from changing the State to Active as you mentioned and after saving/submitting the incident, they will be able to edit the State field in the incident to the desired state. 

This should help the SLA to trigger when it should. 

I hope this was helpful,

Kind regards,
Wuang

[Tommy SN Sahlin]

Hi Straut,

I know this isn't a response to your initial question, but as a comment, it generally isn't good practice to use a State value as a Start Condition for an SLA Definition. The reason is both the scenario you are experiencing - that State value can be flexibly set and therefore generate unwanted consequences - but also since many times, your SLA will be set to cancel when the Start conditions are not met. This can often lead to undesired results.

cheers, hope that helps  /Tommy

[StewartF]

Hi Tommy,

Not sure you've read all of this correctly - the SLA definition isn't set to start on the State field. The pause conditions are, which is correct, but the start isn't defined by the State field.

The State field is being called to make sure that it stays as Read-Only when a new record is created. Only once it's been assigned should you be able to change the state away from 'New'.

When ITIL users were manually changing the state to 'Active' before saving the record, that was breaking the SLA's.

What I have put in place with the UI policy making sure that field isn't changed before the record is saved has fixed the issues, and all the SLA's are correctly firing now.

There have been no undesired effects as the SLA definitions haven't been touched - they are out of the box and accurate.

[Tommy SN Sahlin]

Hi Straut,

gotcha! 🙂 I thought it was the Start Conditions that were messing things up. Then all sounds well!

Just as a comment, if you're using the SLA Definitions completely OOTB, you may want to take an extra look at a few of the Duration values... for example, the OOTB SLA Definition "Priority 4 resolution (2 day)" has a duration of 2 days, which actually means 48 hours. Since it's running against a Schedule of 8-5 weekdays, that means it will breach after 5 business days and 3 hours (9+9+9+9+9+3=48), not after 2 elapsed business days. Maybe that's what you want, maybe not 😉

cheers  /Tommy