Risks of Reopening Closed RITMs/REQs

[LeighAnnB]

I know it’s not best practice to reopen a closed RITM or REQ, but I keep having the same person come to me asking for it—no matter how many times I explain that it shouldn’t be done.

Can I get some examples, explanations, or documentation references to help reinforce this point?

I understand it is technically possible—via UI Actions, Business Rules, or custom Flow Designer steps—but I’m hesitant to create a process for it. The main reason is that we have one or two “click-happy” users who close all their SCTASKs prematurely, then ask us to reopen them constantly. I feel like the better solution is to address their workflow habits, not build a custom safety net.

From my understanding, RITMs are intended to follow a straightforward, linear flow:
Request → Approve → Fulfill → Close

My current reasoning against reopening:

Data integrity – Reopening changes historical records and metrics, making reporting and audit trails less reliable.

Workflow consistency – The request process is designed to move forward in a linear fashion; reopening can introduce skipped approvals or missed fulfillment steps.

Root cause masking – If we make reopening easy, the underlying issue (user error or process gaps) never gets addressed.

Risk of missed SLAs – Reopened items can throw off SLA timers or lead to SLA breaches that aren’t actually valid.

Does anyone have solid reasons, risks, or war stories I can share with my team to reinforce why we shouldn’t be reopening these?

[Dr Atul G- LNG · Accepted solution]

Hi @LeighAnnB 

I’m a BPC and happy to share my thoughts. Reopening a record—whether in ServiceNow or any other system—is always a critical action that requires validation. The reason reopening is discouraged is because it can impact SLA calculations, distort reporting metrics, and violate core system integrity principles.

In your case, you mentioned three valid points, so we need to carefully consider what reopening actually means. A record may technically be reopened, but what happens if a business or technical activity has already been completed against that request? Will you revert that work too? How will you handle such scenarios?

Additionally, when reopening a record, several important questions arise:

• What will be the state of the REQ or RITM after it is reopened?

• Who is responsible for reopening the record?

• Why was it reopened in the first place?

Without a clear process, this can easily turn into a blame game. For example, what if a user unknowingly reopens a request? There are many such scenarios and questions, and currently, there’s no defined process in place to address them effectively. This makes reopening risky and potentially disruptive unless it's well-governed.

This can create a mismatch between the actual work done and the current state of the record, leading to inconsistencies and confusion. So, reopening should only be done with a clear understanding of its impact and a defined process to maintain data and process integrity.