nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

parallel task rejection

brin

Hi,

We are using Interwoven TeamSite 6.5.0 with Service Pack 2 . I need a clarification in the below scenario for a workflow. Want to know if it is possible or not.

SCENARIO
Task1, Task2 and Task3 are group tasks.
Task3 becomes active only iff both (and activation) Task1 and Task2 users approve their work. In this case once the Task3 becomes active he has the options to reject back either to Task1 or Task2 or both.

ie
grouptask = Task3
succ1 -> reject Task1
succ2 -> reject Task2
succ3 -> reject both
succ4 -> approve

when I do "reject Task1", the Task1 becomes active. Now again when I approve Task1, the task doesnt transition to Task3. I know that it is because we are anding Task1 and Task2. But is there any possibility for this condition to work.

Thanks in advance.

Best Regards
Brinda

Find more posts tagged with

Comments

Migrateduser

Have you set a Reset transition from the Task C to Tasks A and B?

-Dixit

brin

Hi Dixit,

Yes i did that too, but with no luck. Any other idea.

Best Regards
Brinda

Pratheesh

Try resetting only 1 task and try...

brin

Hi Pratheesh,

That too doesnt work

Best Regards
Brinda

kaalraa

Hi Pratheesh,

That too doesnt work

Best Regards
Brinda

We might need your wft file as in attached.

ISCBorisB

Hi Pratheesh,

That too doesnt work

Best Regards
Brinda

There are many ways to accomplish something like that. IMO the simplest one is illustrated by the diagram below.
In it you would have to set two Tasks for Approval 1 and 2 each and then just link them correctly.


                      (Back to T0, T3, T4)
          (T1)App 1        \
         /         \        \
start--(T0)dummy  AND--(T5)App 3--Approved
         \         /   /  /
          (T2)App 2   /  /
                     /  /
          (T3)App 1-   /
                      /
          (T4)App 2--

brin

Actually mentioned below is the exact scenario as to how the tasks transition.

Task1 -> emailtaskA -> Task3
Task2 -> emailtaskA -> Task3

When Task3 rejects Task1, what happens is

Task3 -> cgitaskA -> emailtaskB -> Task1

similarly if Task3 rejects Task2, then

Task3 -> cgitaskC -> emailtaskD -> Task2

All are different tasks, so I am not sure where to add the reset/inactivate exactly. The and activation of Task1 and Task2 is done in the “emailtaskA”. Can anyone give some idea on this.

Best Regards
Brinda

Adam Stoller

It's been a while since I've dealt with concurrent workflow processes, and while I think this diagram is pretty much the same as ISCBorisB's it might be a little clearer:

             +-> (rejected) -> ERej0 (inactivate R2) -> UT
            /
      /-> R1 -> (approved) -\
ERev0+ (reset R1&R2)         +-> ERev3 -> R3
      \-> R2 -> (approved) -/
            \
             +-> (rejected) -> ERej1 (inactivate R1) -> UT

----/\-------------\/----------------/\-------------\/-----

   +-> (approved) -> ...
R3 +-> (rejected R1) -> ERej2 (reset R1) -> R1
   +-> (rejected R2) -> ERej3 (reset R2) -> R2
   |                                            /-> R1
   +-> (rejected all) -> ERej4 (reset R1, R2) -+
                                                \-> R2

In this case R1 and R2 are concurrent review tasks, R3 is activated only if both R1 and R2 approved the work (that part's simple).
If R1 rejects the work, ERej0 is activated to send email back to the user indicating that the work was rejected and you inactivate R2.
If R2 rejects the work, ERej1 is activated to send email back to the user indicating that the work was rejected and you inactivate R1.
(so far we're still in the pretty basic concurrent stuff)
If R3 rejects back to R1, ERej2 is activated to send email back to the owner of R1 and you reset R1
If R3 rejects back to R2, ERej3 is activated to send email back to the owner of R2 and you reset R2
If R3 rejects both, ERej4 is activated to send email to the owners of both R1 and R2 and you reset both R1 and R2

Some of these externaltask's or cgitask's (if you wish) could be combined with some fancier code - but for the first-pass verification, I'd recommend having them all be separate tasks for specific purposes. Insert additional tasks within the process flow as you see fit.

I believe that's right - but as I said, it's been a while since I've had to deal with concurrent tasks.

brin

Hi Boris,

Your idea worked. Many thanks.

Best Regards
Brinda

brin

Thanks all for your time and ideas.

Best Regards
Brinda