cancel
Showing results for 
Search instead for 
Did you mean: 

Deadline monitoring- Multipe level escalation

Former Member
0 Kudos

Hello All,

I have gon thru' the available threads regarding this subject, but still could not find clue how to achive my requirement, so mentioning it here for your help.

Pls suggets:

In my scenario, I have to use the deadline monitoring. If approver does not act upon work item for 2 days, I have to escalate and send the work item to next escation level.

Also another point is that while work item is sent to next level, work item should be available in previous approval level.

And when it is acted upon by any approver, then it should be removed from Inbox of approver's on other levels or on the same level .

Awaitng your help.

Thanks in advance.

Regds,

Akshay Bhagwat

Accepted Solutions (1)

Accepted Solutions (1)

Former Member
0 Kudos

Hi,

You can also achieve the same without using the local events also. Use the same fork step and let each branch represent the different level of escalations. For example if you have three levels of escalation have three parallel paths (1 out of 3). Let each parallel path have approval step for each level. Leave the first approver step as such as he is going to receive the workitem immediately.

In the second parallel path include a requested start deadline which will start only after the required time delay (2 days). So the workitem will be available in his inbox only after 2 days of creation of the workitem/workflow.

In the third parallel path you can set the requested start in a similar way such that it starts after the required delay (say 4 days). Now the workitem will be available in the third approvers inbox only after 4 days of creation of workitem/workflow.

Since its a 1 out of 3 fork step the workitem from other users will be logically deleted when one of the approvers process it.

Thanks,

Prasath N

Former Member
0 Kudos

Hi Prasath,

Thanks for the reply.

I was also thinking on the same lines. However I'll tell you now the factor which might affect while designing the workflow with fork.

I have 3 different regions say A , B and C. All have different hierarchy. So we will be actually maintaining 3 custom tables for agent determination.

Now, in region, we need to have escaltion upto levels say 4 , whereas in B we need to have it for 3 levels and in C fro 2 levels.

So in such case if we design Wf with say 4 branches with fork , i was just thinking how it will work for region B & C.

Another option of thinking was shall I create 3 differnt templates so that htis problem can be solved. But.. If they add a level in custom table i.e. number of escations increas in futur, then how will the Wf will be adaptable?

Appriciate your opnion on this.

Regds,

Akshay

Former Member
0 Kudos

Hi Akshay,

Yes I think the best option would be to create three different templates. If you can get the number of escalation levels as an event parameter then you can use start conditions to start the right template.

<i><b>

If they add a level in custom table i.e. number of escations increas in futur, then how will the Wf will be adaptable?

</b></i>

I am not sure about the feasibility of the above requirement because the design of the workflow template itself will be affected for this requirement. You said you have three custom tables for agent determination. So the number of entries will decide the number of escalation levels. If you can manage to get the number of escalation levels as a event parameter then there can be a work around for this. You can use this parameter to start the right workflow template.

Assume you have 5 individual WF templates for each of the escalation levels (This should not be more complex because each of the workflow will be a copy of the other workflow with one more additional escalation). First template will have only one escalation level second will have two escalation levels and so on.

For example I assume region A has 1 escalation level, region B has 2 escalation levels and region C has 3 escalation levels. Now when I trigger the workflow based on the start conditions the following workflow templates will be triggered,

Region A --> workflow template 1 (with one escalation)

Region B --> workflow template 2 (with two escalations)

Region C --> workflow template 3 (with three escalations)

Workflow templates 4 & 5 will not be triggered under the current scenario.

Now if I add one more escalation level to region A (in custom table for A) based on the start conditions the second workflow template will trigger instead of first workflow template. Similarly if I add 1 more escalation level for region C the workflow template 4 will be triggered.

But again there will be a limitation that you can have only 5 escalations (max) possible for any region.

Thanks,

Prasath N

KKilhavn
Active Contributor
0 Kudos

I agree, you can solve this using different templates. You could also solve it by creating a solution similar to the standard FI Release for payment solution from SAP (see the customizing options and e.g. the workflows WS00400012 and WS00400011).

If you use different workflow templates you don't have to use workflow start conditions to prevent the other templates from starting. Instead you can use your own receiver type function module - or use the dynamic task possibility in the workflow builder (similar to what SAP has done in the FI Release for payment solution) to start different subworkflows.

Former Member
0 Kudos

Hi Kjetil and Prasath,

Thanks for your inputs.

At last what I had tried and I am planning to use is a loop. In one of the background steps before this loop, I'll determine no. of agents in multiline container.

Inside loop I will be putting the approval step in deadline monitoring. ( Not using rule as I have some other validations also in this agent determination!)

By this way, I'll have control as based on number of passes in loop, I will be able to select next approver instead of creating 3 or 4 diferent templates.And even if number of entries change in custom table as Prasath was mentioning, will be taken care by loop.

What do you think?

Regds,

Akshay

Former Member
0 Kudos

Hi Akshay,

That is what i suggested.

Regards,

Srinivas.

KKilhavn
Active Contributor
0 Kudos

If you are able to do this and implement a solution where the escalation ends in the work item being available for both the original approver and the approver it has been escalated to (as per your original description of requirements) it is probably a solution requiring less maintenance.

f you could update us with an outline of your solution if you manage to use this approach I am sure I won't be the only one appreciating it.

Answers (3)

Answers (3)

Former Member
0 Kudos

Excuse me for a bit of spam. I just wanted to say: what a great idea with the 3-branches fork! Simple and briliant, bravo Prasath. ... and why only 2 points?

... sorry again, it is a bit boring down here...

Michal

Former Member
0 Kudos

Hi Akshay,

1.Create a LOOP Until Step.Use the conitions according to your requirment.

i.e.If you want the workflow to be stopped if any one of the approver rejects then use a STATUS field in your custom table which will be updated in Step 3.

2.Create an Activity step to find the First approver based on the the region A, B or C.

3. Use a Decision step and pass the Approver from the preious Step.

Depening on the outcome update the custom table field STATUS.

Also use the Requested End option for Deadline Monitoring.

Regards,

Srinivas.

Former Member
0 Kudos

Hi Akshay,

You can use a fork step which has two parallel paths (condition = 1 out of 2). One parallel path can contain the first approver approval step. Also have a deadline monitoring which has modelled outcome when the deadline is reached. In the modelled outcome branch you can include a Raise local event step and raise a local event (say for example - "DeadlineReached")

In second parallel path use two steps. Put a wait for local event - DeadlineReached (if u dont have a standard one) step followed by the second approver approval step.

Now when the workflow initiates the approval workitem will be available with first approver only as the second parallel path will be waiting for the local event. When the deadline is reached the local event is triggered and the parallel step delivers a workitwm to the next level approvers inbox also. Since it is a fork step when one of the approver approves the workflow will end removing the other workitem.

Thanks,

Prasath N