cancel
Showing results for 
Search instead for 
Did you mean: 

Changing approver of active work item in n-step workflow

mh97
Contributor
0 Kudos

Is there a standard approach with the n-step approval workflow (WS14000133), to re-route a work item that is in one user's inbox, when that user has been replaced in the approval chain?

We are using SRM 5.0. I am new to SRM and the n-step workflow but otherwise very familiar with SAP Workflow. Normally with an organizational assignment in a SAP workflow step, I would simply "re-execute agent rules", and that is a task I might be able to assign to an administrative user outside IT. But it appears with the n-step workflow, because the agent is determined in a prior step and passed to the approval step by a container element, that this process first requires editing the container in the technical view of the work item. I don't think that we would give that capability outside of IT.

Does SRM have a standard way of handling this other than editing the container?

Thanks,

Margaret

Accepted Solutions (0)

Answers (1)

Answers (1)

former_member186746
Active Contributor
0 Kudos

Hi Margaret,

In the case of users not working anymore or a similar situation SAP has provided us with the transaction SWIA

Here you are allowed to forward the workitem to someone else (it's the fifth button from the left called Administrator forward Shift F12)

Alternatively you could use a replacement for the user, either from his own inbox (SBWP) goto menupath

Settings>Workflow settings>maintain substitute

Or you can use FM RH_SUBSTITUTES_LIST to do it for the user.

Kind regards, Rob Dielemans

mh97
Contributor
0 Kudos

Rob,

Thank you for your response. I suspect yours is the best answer as far as what SAP has provided. However in the SRM workflow when the work item is forwarded, the container is not updated for the Approvers List. So where we are using the approvers list in a webdynpro screen it will now be inaccurate. Also there will be no check whether the user to whom the item is forwarded is actually in the approval list. I was hoping for a "re-execute agent rules" type of answer so the workflow would be updated to show the new approver as the selected agent, and that would also force the updating of the responsibilities before updating any workflow instances.

However, the administrator forward approach is a good stopgap method, if we can figure out the minimal authorizations and a simple procedure to give the business user who will do this process.

I'll leave this question open for a little while to see if any other ideas are proposed.

Margaret

former_member186746
Active Contributor
0 Kudos

Hi Margaret,

Nice to see some well constructed feedback for a change.

There are other options available though.

1.Restart the process

You set the active workflow to logically deleted and use transaction SWUE to create the same event.

this will in effect restart the process, take heed with changes already done in the previous flow.

2: Manually change the container elements

View the workitem in the transaction of your choice like SWI1

Click the workflow log.

Click on the workflow which containers you want to change

Then use menupath goto-->Technical workitem display (CTRLSHIFTF6)

Then use menupath Edit-->Change (CTRLSHIFTF3)

And then change the container element for the approvers by hand.

The second option I actually had to do for a different scenario once for thirtysomething workitems and I strongly disadvise it.

Kind regards, Rob Dielemans

Edit: sorry forgot that you already mentioned the changing of containers bit in the OP

Edited by: Rob Dielemans on May 28, 2009 8:11 AM

mh97
Contributor
0 Kudos

Thanks Rob.

I think we don't want to do option 1 because then anyone who previously approved will have to approve it again. The business wants to avoid that.

I agree on option 2 that it is something we wouldn't want to do manually. (I don't want to do it and I don't want to give those authorizations to the person who should be doing it.)

I'm going to propose the administrator forward approach and identify the "features" of doing it that way. The only alternative will be to write a custom program to do option 2, and unless the volume is very high, the cost won't be justified, I think. But then if the volume is very high for this situation, I think they should consider that there is another problem!

Thanks again for your suggestions!

Former Member
0 Kudos

i have developed a program for automatic approver change if you're interested.

Former Member
0 Kudos

Hi Antish,

Can you please provide this program. It will be really helpful. Thanks

Regards

Kapil

marco_alva
Explorer
0 Kudos

Antish,

Share your program.

Regards,

Marco

Former Member
0 Kudos

Hello Antish,

Can you plz share your program?

Sonal

Rushikesh_Yeole
Contributor
0 Kudos

I will suggest few points

1. To avoid this issue (Left Employees/Wrong approver assignments), we should use standard t-codes to monitor. We should use substitution method (This responsibility can be taken by Business person. We can develop custom user friendly transaction ).

2. We should avoid Option 2. Such programs can be easily developed using standard FM. But really not advisable. It depends on your workflow versions etc.

3. Logical deletion problem: You can handle in approver BADI depending on process controlled or application controlled WF. The person with Approver Level X and ID ABAC can be eliminated if it has been already approved.