Workflow Substitution

[Former Member]

Hiee!

I am a few doubts over the workflow substitutions which I hope they could be cleared off by any of you, wf experts:

1) Workflow substitutes (active or passive), the substitute profiles could be used to limit the work items that the substitutes are able to view. Is my understanding correct?

2) When assigning substitutes, authorization is not passed over, which means the approver assigning the substitutes and admin has to assign the authorization, in order to complete the substitution process?

3) For example, in PR workflow, an approver has assigned a substitute. Does the substitute approve the purchase requisitions using his or her own release code or the approver's release code instead?

If using the approver's release code, is there any way of making it become the substitute's release code through the substitution process, for better tracking?

Thank you so much for your advices, suggestions, opinions and help.

Regards,

YL

[Former Member]

1) Workflow substitutes (active or passive), the substitute profiles could be used to limit the work items that the substitutes are able to view. Is my understanding correct?

Actually the Profile is assigned according to Task. So if you want your substitute only to approve Leave request and Not Travel expense you can accomplish this by using this feature

2) When assigning substitutes, authorization is not passed over, which means the approver assigning the substitutes and admin has to assign the authorization, in order to complete the substitution process?

The question is a bit confusing For making Substitute the user dont require any authorization. Now if you make anyone a substitute that doesn't mean the authorization profile will also be substituted. When someone is making someone a substitute he should be of the same rank. Like a Manager will make another manager as his substitute hence he will have authorization.

3) For example, in PR workflow, an approver has assigned a substitute. Does the substitute approve the purchase requisitions using his or her own release code or the approver's release code instead?

He would be approving for the particular Workitem Release code. If the substitute is the next approver he will get the workitem again for Release.

Thanks

Arghadip

[Former Member]

Thanks, Arghadip, for your replies.

I am just wondering:

1) Let say the substitutes happened to be the assistants of the approver (lower rank). Is it a good practice that I assign them as substitutes in SBWP and I assign the authorization to approve (with delimited date) on them?

2) "He would be approving for the particular Workitem Release code. If the substitute is the next approver he will get the workitem again for Release."

From my understanding, what you meant is, let say the PR is having a release code '06', even if I assign substitute, the substitute is still approving the PR with the release code '06', right?

What if for tracebility, I want to cater for the scenario where the substitute would be approving the PR with his/her own release code instead?

Thanks,

Yen Li

[Former Member]

Hi Boo. Authorization to execute the workitem is managed under task level (Possible agent). So, if some one assign substitute in SBWP, they should make sure substitue also belong to the possible agent set in task level. Regarding release code, it is something to do with workflow.

[Former Member]

Hi, jrockman. Thanks for your replies.

So, do you mean I should actually included the substitutes as agents, together with the approvers in the "Possible Agents" for the particular task? Or do you mean that I only can select any of the approvers as substitutes?

If it's the former that you meant, do you mind to share why it is advised to do so and how it relates back to the substitution in SBWP? Or the substitution should be catered in workflow instead?

As for the substitute's release code, can you please kindly suggest a way how I could include that in my workflow?

Thanks a lot,

YL

[Former Member]

1) Let say the substitutes happened to be the assistants of the approver (lower rank). Is it a good practice that I assign them as substitutes in SBWP and I assign the authorization to approve (with delimited date) on them?

We too have got scenarios where some of our users have substituted their assistants. However good practice is to have someone at par.

What if for tracebility, I want to cater for the scenario where the substitute would be approving the PR with his/her own release code instead?

I understand this can be set within the workflow. Substitute or not, for each approver try to find the relevant release code as per authority/hierarchy level and pass to the release method.

So, do you mean I should actually included the substitutes as agents, together with the approvers in the "Possible Agents" for the particular task? Or do you mean that I only can select any of the approvers as substitutes?

If your task is a "General Task" then no need to worry. Only in cases where decision tasks have restricted authorizations, the approvers must belong to the "Possible Agents" set.

Edited by: Manish Khanna on Oct 13, 2008 6:14 AM

[Former Member]

We too have got scenarios where some of our users have substituted their assistants. However good practice is to have someone at par.

Do you mind to share how you do that, as in the authorizations to approve the PR (for example) are assigned after substitutions externally, etc?

I understand this can be set within the workflow. Substitute or not, for each approver try to find the relevant release code as per authority/hierarchy level and pass to the release method.

I am sorry, but I am lost on how to implement this, do you mind to explain more on this suggestion, please? Does this mean a user exit is needed on the release method to capture who is currently executing the release method and if he/she is a substitute, change the release code to his/her instead?

[Former Member]

Do you mind to share how you do that, as in the authorizations to approve the PR (for example) are assigned after substitutions externally, etc?

In our case the decision task is set to General, so no issues while substituting.

I am sorry, but I am lost on how to implement this, do you mind to explain more on this suggestion, please? Does this mean a user exit is needed on the release method to capture who is currently executing the release method and if he/she is a substitute, change the release code to his/her instead?

check for the container element WiActual_Agent which shows the user who "actually" approved/rejected/...

Based on this user pass on the desired rel code to release method.

[Former Member]

Regarding the authorizaiton part, it is not a good practice to set task as "Geneneral', even though this way can bring convinience for agent to set substitute because it means that all users can have authority to open/execute workitem and will bring potential authority issue. So, i recommand you to set the attribute "General fowarding not allowed", and set possible agents which will include all possible substitutes.

[Former Member]

check for the container element WiActual_Agent which shows the user who "actually" approved/rejected/...
Based on this user pass on the desired rel code to release method.

Sorry, may I know what release method do you mean? If let say I am releasing a PR, so the rel code is displayed on the release page.

But since I assign a substitute, how do I make that the substitute release the PR with his/her rel code instead of mine.

Because, based on my understanding, I would be able to get the element WiActual_Agent only after the release event fired. In that case, the rel code would still be the approver's, unless I have to include substitution in the workflow, instead of from SBWP itself. I wonder if my understanding is correct or not?

The reason behind all these are because that the release code are tied to the person, thus, by using release code, one can determine who the approver is. Therefore, for tracebility, it is better that after substitution, the substitute is releasing the item using his/her own rel code.

Thanks a lot.

Regards,

YL

[Former Member]

may I know what release method do you mean?

The 'release' method of the business object for PR. It contains input parameter for rel code.

Yen, the requirement is bit tricky. So you need to do something tricky as well.

The idea is to release the PR in background and not foreground.

1. The approval work item shown to users should mention that approval will release the PR in background with their release code.

2. Once they approve, in background you would need to find release code for the user(original or substitute).

3. Release the PR in background using this release code.

Hence whoever the user is, the PR will be released by his/her release code.