I get this occasionally from users. They will start the release process on an item revision, only to realize moments later, that they forgot to add a DXF file, etc.
Our current process is for them to finish the workflow (they sign off on it themselves), and then an Tc admin runs a remove status workflow on it.
Is there a way for the user to undo the workflow they started, so they can add whatever they forgot?
OK, I'll have to dig to find out about those handlers. I'm not a Tc guy, I just play one at work :)
Action > Abort will currently finish the workflow (adds the checkered flag)
Quick look in the solution center brought up this, which for me, the inexperienced, isn't that clear. I will add this to our "things to do" list.
Aborting or suspending a workflow Symptom When aborting or suspending a workflow where can I put the handlers as the process owner to send email/set properties etc. Does it need to be on the specific task or can it be on the parent task or root task? Hardware/Software Configuration Platform: INTL64 OS: WINDOW OS Version: XP64_SP2 Product: TEAMCENTER Application: WORKFLOW Solution I created a simple workflow where it has one review task in it. I added EPM-set-property handlers on the Root node, the Review Task node and the perform-signoffs node. In each I set the same property but with a different value (Abort-Root, Abort-Review, or Abort-signoff) to see what is setting it. I submit an item to the workflow and select a reviewer than I go to my task to track and do an Action->Abort and the value is set to Abort-signoff so the handler that is getting called is the signoff one. I then went in and removed the handler on the perform-signoff action and repeated the test and it resulted in Abort-Review, so since in that case that handler on the Review Task is called. So then I removed the handler from the Review Task and the result showed Abort-Root. So it looks like it runs all 3 of them, first the one on the Root node, then the one on the Task node then the one on the sub task. So the lower ones will ultimately win but if one is not there the upper ones will work. I tried the same test with Suspend though and it works differently. Only the handler on the perform-signoff task is ever run, even if one exists higher in the workflow. The reason is that in abort you are kicking it out of the workflow all together so it has to abort out of each level and then has the opportunity to run the code there. With suspend it is only pausing it so it only cares about the current step, and only runs that code.
You can add a handler to apply a Status (checkered flag) when the user aborts, if you'd like, or you can leave that handler out so that after they abort there is no trace that a workflow was ever started.
IMHO an abort action should not be a general case for a user. It results in follow tasks like delete checked flag objects, process objects and some of these can be done only with dba or bypass rights.
Think about to develop smart workflow process templates. Consider validation tasks to check on necessary attachments for these specific processes. If something missing, the workflow doesn't even start. You could also use manual condition tasks to ask the user what to do (follow a specific path in the process). Utilize Sub-processes to avoid redundant tasks.
Make use of following handlers in your workflow process template to check if the
target object contains the attachment. It will not proceed and will ensure users to attach the required file
It checks that the specified target object contains the required attachment with the required status or statuses.
You have lots and lots of options...Here are my favourites
1 - If the user realises during the worklfow, simply get the user to Reject rather than Approve. Then they can add the missing files and resubmit
2 - Create a new workflow that adds the missing files. I have one that adds PDFs and DXFs. it does some validation at the start, tells the user to paste the dataset into the reference folder, and then the workflow creates a relation between the dataset and the revision. The best bit about this workflow is that the user doesnt have write access to the revision on the DO task, so they cant modify anything. Access is granted on the Create Relation task which doesn't pause for user interaction:
3 - If you dont want to use the Reject path of the approval, just add a condition task that asks the user "Have you added all the files? Yes - Continue and Issue, No - Exit the workflow". This would be annoying for users though as asks the question everytime and its extra mouse clicks.
Thanks everyone, for all the suggestions. They are beyond my understanding of workflows, but will make a good discussion for us to decide what we want, and then figure out how to do it.