Re-assigning a work item

[Former Member]

Hi,

I am soliciting solution or some ideas for the scenario below:

A user is assigned to an Approval Object (Notification Task). The user gets a work item in his SAP Inbox. But before completing that work item, the approval task was re-assigned to a new user. The new user gets a work item in his SAP Inbox. Question is, how do I delete the work item from the other user's Inbox.

I was wondering if there's a workflow functionality for this.

Your ideas are very much appreciated.

Thanks.

Giscard

[Former Member]

Your question is not clear

Let me ask you the question?

Agent A->has workitem Inbox currently

Agent B-> Workitem forwarded to

Your question

Remove workitem From A?

Ans: Gets removed automatically when forwarding

Remove workitem From B?

Ans: Execute Rule Exection from SWI1_Rule.

Thanks

Arghadip

[Former Member]

The scenario is not really forwarding the work item from person A to person B.

It is initiated by a change in a field of a certain transaction (task owner field).

There is a workflow that sends out a work item everytime the task owner field changes.

My question is how do I delete the work item from the Inbox of person A (the user the work item was previously assigned to).

[Former Member]

You can either forward the workitem or logically delete it. How to do this you will find in this forum.

Thanks

Arghadip

[former_member185167]

Hello,

You may want to change your workflows so that when task owner field changes it creates an event which will complete the previous workflow. The previous workflow will have to listen out for that event.

regards

Rick Bakker

Hanabi Technology

[Former Member]

questions is, how do you go back to the previous workflow from the current workflow that was triggered due to the change in the task owner field?

[former_member185167]

Hello,

You "go back" by having the change create an event which will terminate the previous workflow - it listens out for that event.

regards

Rick Bakker

Hanabi Technology

[Former Member]

Hi Giscard

To add to Rick' suggestion, the "link" between the two is the common object key. The started workflow will be "waiting" for the event that gets triggered when the field value is changed. This will result in termination of the previous workflow and starting the new one.

Good Luck

Ravi

[Former Member]

Did you mean to put a "Wait for Event" step in one workflow AND

put an "Event Creator" step in the other workflow?

Shouldn't they be in the same workflow to work?

[Former Member]

Have you actually got 2 different workflow templates or just one, please clarify. We thought there was just one.

Cheers

Ravi

[Former Member]

Hi Ravi,

Thanks for the info.

So the the event created from one workflow instance is visible to another workflow instance through the object key?

I think I am getting the picture now.

Do I have to put the Wait for Event step in a Fork together with the Activity step?

Thanks.

Giscard

[Former Member]

I can have just one workflow.

But I will definitely have 2 workflow instances.

First instance:

Task owner field was changed to user A. Work item gets sent to Inbox of user A.

Second instance:

Task owner field was changed to user B. Work item gets sent to Inbox of user B.

Will the "Wait for Event" step be visible across those 2 instances?

[Former Member]

Hi Giscard

You basically need to have Activity step and the Wait step in parallel paths, so completion of one will complete the workflow, if that's what you want to achieve.

Good Luck

Ravi

[former_member185167]

Hello,

"Will the "Wait for Event" step be visible across those 2 instances?"

Yes it will, but there is a problem - what BOR object is the basis for these workflow instances?

Does the key of the object contain the assigned user? If not, having a wait-for-event step

will stop both workflows.

You could create a separate object, and listen out for an event from that object, which does contain the user in the key.

Or, probably easiest of all, you could have the workflow listen out for the change-user event and instead of completing the workflow it could re-route it to the other user.

regards

Rick Bakker

Hanabi technology