Different methods for handling Work items –in error / to restart/ to delete

Handling Work Items in Workflow can be quite a challenge .Below are some of the common issues I failed in SRM for which I am writing this article in place .

Problem Areas ??

1. The work item which appears in the inbox for all approver since the Agent determination did not run properly or maybe you don’t need the work item at all now and want to get rid of it .

2. Delete the Item from the approvers inbox since it is not needed anymore .

3. SC went into error in transmission and you would like to restart the workflow

4. You may want to analyse why the work item got into error ?

Below are the couple of methods 4 in total to help you solve the above queries :

OPTION 1 : LOGICALLY DELETE .This is the option called as logically delete which basically means the workflow would cease to exist in the portal though it still does exist in the backend . This is for issue 1 to 3 where we have a Work item ID as below in which the SC is awaiting approval .

However when we check the responsible agents all users can carry out the task .

(What causes the issue would constitute another Document )the work around is what I am describing here to get rid of the work item in such cases .

How to Logically delete :

To get to the below screen . Go to BBP_pd and copy the work Item ID from there .

Find the work flow ID : and go to SWIA and to the below screen where you can find the corresponding error as it lists all the agents ..

Double click on the last line “ Approve Shopping cart ..” and it will take you to the next screen as below

Here choose “ Technical work item display “

Now in the same you would get the Edit option where you can choose to Change the Work item ID .

Please note :

Logically delete would delete the cart though its existence would still remain in the backend system .

These workitems are then immediately removed from users’ inboxes and it also delete the child work items . So ensure you delete at the higher level before it starts causing issues .

OPTIOn 2 : Use transaction SWWL OR report RSWWWIDE

However this is not a recommended approach in production Since it not only deletes the work item from the front end and backend it also deletes all instances so it creates issue incase of audit purposes .

See the 2 options marked in yellow .

OPTION 3 : /SWW_SARA to delete

With this function you write the workitem data to an archive (a file) before you delete them, In real life you won’t import them again, but you audit trail will remain intact, and you are able to retrieve it again with transaction SWW_ARCHIV.Furthermore SWW_SARA only deletes work-items with status “Completed” or “Logical_deleted” where SWWL will delete any workitem, so with the wrong selection criteria in SWWL – you will face the risk of deleting active / live workitems accidentally. and you are able to retrieve it again with transaction SWW_ARCHIV

OPTION 4 : SWI2_DIAG For restart of Workflow

Only thing we need to enter as input is the workflow monitoring period:

This would show the over all errors and also can be used to restart any of the erroneous workflow transactions ..

You may double click further to get the new screen as below with the descriptive Error text data .

Further double clicking may help you with the possible resolution or to help you find the relevant OSS .

Hope you like this article .If you do please leave a comment and your feedback and don’t forget to rate the article . Thanks all

SAP Note 1286336 (‘New logically delete function for mass processing’) adds the function code ADMC (Administrator Cancel) to transaction SWIA. You can check the SAP Note to see if you already have the requisite support pack; if not, you can use SNOTE to put this note in yourself.

Hi Rick thanks for the input .. if you read carefully I already have incorporated most of the points which you pointed out and for the rest I shall make a note and do the changes in the article .. Thanks for reading and providing feedback .

I have to agree with Rick about all three cases. You should make new instructions (with new screenshots) about logically deleting the work item (“How to logically delete the parent work item”). It would be good to have good instructions about how to delete the parent work item of a workflow, because this is so common mistake to just delete the single work item.

Also, I would remove the whole part of SWWL. SWWL is repeatedly mentioned in various threads here in SCN, and in 99% of cases it is always wrong. You simply should not use that report in production environment.

Ah yes, we’ve all been in that situation where a ‘general task’ workitem has embarrassingly gone to everyone’s inbox (including the CEOs) in Production.

How do you remove it in a hurry?

I personally would not recommend using the options described above.. deleting or archiving is just too drastic.

One solution is to reserve the workitem for yourself, which immediately removes it from everyone else’s inbox. Then you have time to contemplate the problem and fix it, without your manager constantly asking for status updates :-).

You could also just forward it to the correct agent, if you know immediately who that is.

And I agree with Paul- there are some protections in the system against this happening but the quickest way to resolve it is to reserve the work item, reassign it, and then work back to see why it didn’t find the correct person – which is usually a data or a design problem. Mind you even if it is a data problem, your design should aim to avoid no-one being assigned by assigning some sort of user of last resort.