Manually cancelling a ritm results in a incorrect RITM state

ChrisWing · ‎07-30-2025

I have built a number of catalog items that will end up in a timer waiting for a future date. One of these as an example is a temporary network access for a vendor. We will create a task to provision the access then it will proceed to a wait timer before generating the remove access task. The issue at hand is the vendor finishing early and our needing to deprovision sooner. Without overly complicating things there is no way to shift the flow from the wait timer to an alternative tract so we are opting for a specific team having the ability to "complete" the request. The Service Desk team also needs to be able to cancel some requests that are in mid-stream but have been aborted. We see the cancel request as an option for Catalog_admins, so initially I started down that path however with code derived from the community we decided instead to create form buttons for them at the RITM level that will also close the parent REQ and the child SCTASKs. The buttons and the outcome work as expected. The issue at hand is that when cancelling the RITM, it will change to Closed Incomplete however the OOB Task Closer BR comes along right behind and updates it to Closed Complete. Without manipulating that rule I am struggling to figure out how to have the cancelled tickets remain in a closed incomplete state.

Appreciate any insight someone has for this.

jMarshal · ‎07-30-2025

I see. Sorry - I didn't absorb your initial post fully...I assumed you were initiating the cancellation from an assigned task.

I think you've got a bit of an issue at hand with the overall design of this process (in concept) because you're closing a RITM before all SCTASKS are closed -- this will always cause some issues. You may find other OOB features which are "funky" as they are expecting/assuming a RITM to be "open" (active = true) when processing task actions - this is one thing you're discovering, but there may be more.

...but that's ok, it seems like you understand your use case so I'll get off the soapbox.

I think a supplementary before insert br which triggers on update of sc_req_item which looks at the previous state value and compares to current where it will change back to previous when previous is "incomplete" and current is "complete" should work....you may also want to add a condition that ensures this is for the specific catalog item you are using. Maybe also a condition for "active= false" as you know these will always be on RITM records that are already "Closed Incomplete"

I still wouldn't adjust the oob BR...which triggers on sc_task and initiates the update on sc_req_item, which would trigger your supplementary BR....?

Maybe I'm still misunderstanding your use case, but I hope this also helps!

View solution in original post

ChrisWing · ‎07-30-2025

@jMarshal

I think you nailed it on the head the second time, I am not concerned on the open SCTASKs because I am closing those at the same time, remembering we are stopping the RITM in it's tracks for a very specific reason, we do not want any open tasks to be completed as we are aborting the flow. I will try the approach you mention of a before insert and I do think limited it to specific catalog items right now will be fine though in the future may become a pain to manage.

jMarshal · ‎07-31-2025

oh, fantastic way to handle that (closing the sctasks at the same time). If you don't mind, please accept my answer as a solution/answer or mark as helpful. Thanks! 🙂