Edit fields on a closed incident - advices and best practices ?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
5 hours ago
Hello,
In our organization, when an incident is resolved, it will automatically move to "Closed" after 10 days.
One of the requests we've received is to be able to modify certain fields once the incident is closed, as it may have been incorrectly classified. This is something we currently don't allow.
So the data is extracted from ServiceNow and injected into another tool where the fields can be reclassified to then produce reports.
The data that we want to be editable once the ticket is closed (non-exhaustive list):
- Creation date
- Cause
- Category
- Service
- Resolution date and time
- SLA compliance indicator (OK or KO)
- Priority
Are there any companies among you that have authorized these actions? How did you implement it, and what challenges did you encounter?
Do you have any advice or best practices to share with us? I'd also appreciate ServiceNow's opinion on this matter.
Thanks in advance!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
5 hours ago
As a BPC (Business Process Consultant), I never recommend making any changes to incident records once they are closed. This goes against best practices and can compromise the integrity of the process.
For example, in your case, if the Created Date is auto-populated and you modify it afterward, it could distort monthly or category-based reporting. Subcategories, user SLAs, or cost center dependencies may also rely on original values. Additionally, Priority is often the source of SLA calculation — changing it after closure could falsely impact SLA reporting.
If a user opens a closed record later and finds key fields altered, it raises questions about data reliability and auditability.
In short, it is strongly discouraged to change any field once an incident is closed."
If my response proves useful, please indicate its helpfulness by selecting " Accept as Solution" and " Helpful." This action benefits both the community and me.
Regards
Dr. Atul G. - Learn N Grow Together
ServiceNow Techno - Functional Trainer
LinkedIn: https://www.linkedin.com/in/dratulgrover
YouTube: https://www.youtube.com/@LearnNGrowTogetherwithAtulG
Topmate: https://topmate.io/atul_grover_lng [ Connect for 1-1 Session]
****************************************************************************************************************
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
4 hours ago
As per best practices, do not update incidents that are in 'Closed' state and fields are non-editable for a reason when incident is auto-closed.
If this is a MUST, look at option of extending auto-close period from resolved to closed state rather than allowing to edit Closed Incidents.
Refer below knowledge article for steps to follow if you wish to increase the auto-closure period between resolved to closed state
https://support.servicenow.com/kb?id=kb_article_view&sysparm_article=KB0552820
As per community guidelines, you can accept more than one answer as accepted solution. If my response helped to answer your query, please mark it helpful & accept the solution.
Thanks,
Bhuvan
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
4 hours ago
Though this is technically possible ( need to change ACL) but not recommended.
This can cause serious Audit / data correction issues and not recommended for a mature organization.
Example: An incident has been closed for a category/sub category combination, if category / subcategory is changed after closing, the resolution, assignment group will not match the cat/subcat value. This is a data correctness issue.
Another example, suppose an incident has been closed as P1 and then it is changed to P3, After few days again similar type if P1 is raised the team who resolved it earlier may again look into closed incidents (for resolution) and find it as P3 and lower the priority of current incident.
There are multiple drawbacks to this.
Please mark the answer correct/helpful accordingly.