Skip to Content
Author's profile photo Vinita Kasliwal

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 :

  1. Logically delete would delete the cart though its existence would still remain in the backend system .
  2. 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 ..

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

Useful Workflow T codes:

Other Ref articles :

Notes to Refer

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.

Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Rick Bakker
      Rick Bakker


      I'm sorry, but I have to disagree.

      1. Logically Delete

      You should ONLY logically delete the top-level workflow, not the workitem!

      2. Use transaction  SWWL  OR report RSWWWIDE

      You should never ever use these in a Production system. Or any system! So, best not to mention them at all

      3. Archiving

      You can only archive Completed or logically deleted workitems, so it's not an alternative solution.


      Rick Bakker

      Author's profile photo Vinita Kasliwal
      Vinita Kasliwal
      Blog Post Author

      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 .

      Author's profile photo Former Member
      Former Member

      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.

      Kind regards,


      Author's profile photo Paul Bakker
      Paul Bakker

      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.

      Thanks for sharing



      Author's profile photo Jocelyn Dart
      Jocelyn Dart

      Please note:

      Physical deletion is potentially very dangerous to the continued operation of open workflows and should NEVER be used in a production system.

      Please make sure you read the blog for a better understanding of why... Don’t try this at home: Why you should never physically delete workflows

      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.