The request was closed, again made to work in progress, then again closed.

partnerswat
Tera Contributor

There is a catalog with an automated flow. If the automation fails, a catalog task is created to address the issue manually. A user raised a request, and the flow executed, closing the request automatically. However, within the next 2-3 seconds, the request reverted to 'work in progress' and created a manual task. After some time, the request was closed again, but the catalog task remained open. The flow is generally working fine, as only some requests encounter this issue. How to fix this? 

3 REPLIES 3

Uncle Rob
Kilo Patron

Impossible to tell without much deeper analysis.
What Flow or Workflow is the RITM governed by?
If its a Flow (vs a legacy workflow) can you duplicate the problem?
If you can duplicate the problem, what are the Flow execution logs showing you?

If its not a workflow or a flow, what business rules have been customized on your sc_req_item and sc_task tables?

Dr Atul G- LNG
Tera Patron
Tera Patron

Hi @partnerswat 

 

Look like the flow is running in loop or any job running in backend which open the records.

*************************************************************************************************************
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]

****************************************************************************************************************

John Gilmore
Giga Guru

There are a couple things that we can deduce from the information provided.

First, the flow(s) that are changing the state at 58:08, 58:09, and 58:11 represents either a single flow with a flawed logic loop, or multiple flows acting on the same field. Review which flows/processes are updating the state field and their execution details should clarify why it did that.

Second, it appears that some flow/process was attempting to lookup a user and returned no result or has improper logic with regard to a flow decision that is dependent on the lookup. This generated the apparent error at 58:08 which either occurred twice or has a retry function. Without knowing more my assumption would be that this is also what results in assignment to the manual queue or creation of a manual task.