Manually cancelling a ritm results in a incorrect RITM state

[ChrisWing]

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.

[Yousaf]

Hi @ChrisWing 
Since you dont want to make changes in OOB BR or make clone of it and make updates there (assuming)
Maybe you could try to have a field which you can use as a flag which will be false as default but it will be true if you cancel the flow (will have to use this condition in cancel script/flow)

and have a br triggering after updates to check if flag field is true update state to closed imcomplete

[jMarshal]

What you have discovered is true...and there is really no way to solve it without specifically rolling-up the desired RITM state from the Flow/Workflow in each individual Catalog Item.

I have a subflow that I created for this as all (most) of our Catalog Items will be considered as "cancelled" (Closed Incomplete or Closed Skipped) if/when one of the associated SCTASKS are closed in that manner...but that's not a truism for all potential catalog item flows.

My flow developers can then just use that subflow at the end of any branch in a Catalog Item flow, which has a Service Catalog Task created (and theoretically closed)...IE, when the sctask is closed, call the subflow and handle the RITM according to the defined rule (which is a general use case for this subflow).

...but not all Catalog Item flows use that subflow because that subflow only handles the 80% general use case scenarios (defined through our Request Fulfillment governance as - if a task is skipped or incomplete, the request itself is cancelled as incomplete or skipped...whichever was used as the sctask close code). 

Some of our Catalog Items then require specific handling in their specific flow...sometimes if a task is skipped, the rest of the work continues...so in that instance, the flow dev doesn't use the subflow, but rather designs this behaviour into the specific flow (on the branch for that specific task which can be skipped and not cancel the RITM).

The OOB BR just handles the "generic case" of "when all tasks are done, rollup the RITM, roll up the REQ" - and "Closed Complete" is the most appropriate stage/state for that "generic case" action.

Consider how a REQ has multiple RITMS which could have multiple SCTASKS...what percentage of each would "roll up the parent" as "Closed Skipped" or "Closed Incomplete" as opposed to "Closed Complete"...in all cases would a single SCTASK being closed as skipped (for example) cause the entire thing to rollup as "incomplete" or "skipped" (even if all other tasks are complete?).

This cannot be answered definitively in a general (oob) sense...and that is why it must be defined by your specific flows, only you (as the business user) can determine what this should look like in each specific instance.

Unfortunately, this requires a lot of business process mapping (to your flow/workflow)...and does require exhaustive  scenario analysis (edge-case identification) to get "perfect"...or to automate effectively without error (depending on how complex your flow is, of course).

I would STRONGLY recommend against modifying the behaviour of the oob BR and instead handle it as needed in the individual flows.

The only way I would (as an architect or platform implementer/senior developer) recommend altering that BR to achieve this effect "platform-wide" (offloading the overhead from the flow developer without using a subflow) is with strict Request Fulfillment governance (read: executive understanding and support) that clearly outlines the "rules" about what it "actually means" (to your business) for something to be "complete" vs "incomplete vs "skipped"...as a "percentage of" what individual tasks have been "successful" vs "incomplete" vs "skipped"...and you'll likely discover that this doesn't even make it past the governance table when you ask what to do with a RITM which has 3 SCTASKS - one complete, one incomplete and one skipped...without any other information present about the specific outcomes of those tasks (as this is supposed to be a general case to justify you modifying the oob BR).

Hope this helps!

EDIT = also consider the difference between "Stage" and "State" for a RITM - these seem synonymous but are not, they are separate and need to be addressed separately. Usually when exposing detail to a client end-user, you want to use "Stage" (Fulfillment, Approval Reqeusted, Delivery, Provisioning, Complete, Cancelled) and for an internal report (for platform users), "State" (Open, Pending, Closed Complete, Closed Incomplete, Closed Skipped, etc.)

The subflow I mentioned before only ever sets "Stage = Complete" and "State = Closed Complete", or "Stage = Cancelled" and "State = Closed Incomplete", or "Stage = Cancelled" and "State = Closed Skipped"....this is how we essentially "collapsed" the behaviour of a fulfiller, technician or agent closing a task as "incomplete" or "skipped" to "rollup" in a "client view" that is helpful, as well as a "report view" which is also helpful (to the audience which needs it).

...I hope my edit here also helps you understand how nuanced this is...which also helps understand why modifying the oob BR behaviour is not a great idea.

[ChrisWing]

@jMarshal 

Appreciating what you're saying but this a very narrow case.  I am manually cancelling the RITM and it is the ritm state that I am concerned with reverting from incomplete back to complete due to that business rule.  I don't care the state of the REQ really.  While we don't typically use order guides or have mutlple ritms associated to a single REQ it is worth noting that the way I am achieving the result today would in the future if those situations occured cause the REQ to close even if other RITMs were perfectly valid and did not need to be cancelled. 

 Achieving this solution via a flow won't work because the flow isn't at play here, we are taking a in progress ritm and cancelling it, basically cancelling the flow.  That leaves any sort of solution soley in the realm of a business rule against a table.  We ideally don't want to touch the OOB but we also want to create a situation where it isn't ran (if RITM is Closed Incomplete, do not run).  Just want to ensure we achieve the best practice for it.  I would imagine I could do a condition in the Task Closer BR but that would then create a skipped record and any future coding would need to ensure that is updated appropriately.  I was just hoping there was a different easier solution to cancel a RITM that is in progress that can be provisioned to a specific user group.

[jMarshal · Accepted solution]

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!