Cancel Process Smart Service

Question

We have a request I am working on and can not figure out. A user does something in the system adding records to a table, a process task is started so another person can verify and if approved it goes ahead and approves it, if they reject it with a comment it is sent back to the original person to look at. 
 They now want the ability so the original request can be deleted if put in in error, we have that part working. But we are wanting to use the Cancel Process Smart Service to cancel the process task. It is wanting a process id and can not figure out how to get the process id for the first entry when the user inputs the data. 
 So the user inputs the data and the process is created for the task. But then a little bit later the user goes back in and deletes the data they input, it will only allow them to do this if it has not been approved yet. The process task that was created is still there and now need to cancel it. 
 Any idea on how to get or find the process id for the task that was created so when the user deletes what they did it can cancel the process task also? 
 Thank you

Mike Schmitt · Accepted Answer

I usually recommend, if at all possible, allowing a user to cancel their own task (though i'm a little unclear if this is what you mean here), using a "cancel" button on-form which will route directly to a terminate node in that process. 
 If you really do need to cancel the process externally, you can access the process ID in at least 2 common ways. The most common is probably by use of the Query Process Analytics rule called in the context of the process model in question, filtered down by some other identifying info, which can return the process ID as well as all kinds of other metadata depending on what Process Report you use to source the data from. 
 The second most common way (and easiest, if you set it up in advance), is to have the original process store its own process instance ID to the database shortly after initialization, i.e. in a dedicated column you set up in an existing table & CDT, as in something that specially handles that process.

Mike Schmitt · Answer

williamm0010 said: it needs to cancel that original process task 
 What "original process task" are you referring to here? By the time User 1 has submitted their information for review, their "task" no longer exists as it's been submitted. If you're talking about the process belonging to the Reviewer, why wouldn't that review task be contained in the same original parent process thread? In that case all you'd need to do is terminate that process.

Mike Schmitt · Answer

did you see my followup questions from earlier? I'm still super unclear whether you even need to bother with this. It would be helpful if you could share some screenshots of your process flow indicating what you currently have configured and/or what you hope to accomplish as well. 
 In any case... You will want to use an expression rule to handle your Query Process Analytics call. You can open a blank Expression Rule Editor by manually navigating to /suite/design/ rule in your environment, and just manually messing with it there. Eventually you'll want to save it as an expression rule such that you can pass in the unique id (in terms of process data) that you need the process instnace ID for, and as a result it'll pass out the process ID and/or a collection of metadata relating to that process instance. 
 As an initial step, I'd suggest you create a new / tester Process Report where you can add/edit the various columns as you see fit; then you'd create a constant pointing to that report, and use that constant in your QPA call in your expression rule.

Mike Schmitt · Answer

So to confirm, are you saying "User 2" is different from the "Reviewer" who would be comleting the "Waiting for Approval" task initiated as part of the original process flow? 
 What is User 2 doing to access this information? When you say "click on the link to the interface", what is the link, what type of link is it, and where / what is the interface? Are they seeing the item's record entry? Are they clicking into the "Waiting for Approval" task? Are they seeing it on some arbitrary report? Are they starting a Related Action / other arbitrary process model/instance? 
 There are, of course, various solutions for approaching this, but they all depend on having a good bit of understanding of what the various Appian components are, and do, and what capabilities we have at our disposal; as well as details (hence the above follow-up questions) regarding what the current setup actually looks like.

Chris · Answer

I don't have anything to add other than, as Mike noted earlier, I always always store the process instance IDs (pp!id) to the CDT along with the request data. Then when you want to cancel a process, you have the process IDs of the submission, approvals, along with your main data that you can pull to access/cancel any process instances necessary, without additional analytics querying.

Chris · Answer

I can't say I've fully digested your use case here yet, but I just store process IDs in the same CDT where the submission or approval data is. E.g. if the row has all of the unique ID, submission data, approval process ID, you will have it readily available when you are looking at the data to cancel/delete. Vs having a separate mapping table to manage. Mapping table would work also, but is a lot more overhead.

Cancel Process Smart Service

Top Replies