The request was closed, again made to work in progress, then again closed.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
06-09-2025 04:08 AM
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?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
06-10-2025 06:41 AM
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?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
06-10-2025 12:41 PM
Hi @partnerswat
Look like the flow is running in loop or any job running in backend which open the records.
****************************************************************************************
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
****************************************************************************************************************
Known Issue in the ServiceNow Community
Currently, there is a limitation when embedding screenshots directly into a Community post or question. Members may not be able to download the image or zoom in sufficiently to view the details.
For better visibility and quicker resolution, you can either:
Attach the image as a file so members can download and view it at full resolution, or
Embed the image using a larger image size. This needs to be done manually when creating the post.
This is a known Community limitation and is worth keeping in mind when sharing screenshots that contain detailed information.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
06-10-2025 12:53 PM
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.
