Clarity

Hello Everyone, 

I have created the parallel split workflow which needs to go the two different approval group at same time and merge the result. I am getting the below error message which I dont have any clue what is the pre-requisite for Parallel Split. Could anyone assist on this request would be helpful ?

Start Step : 

I created sample process with Parallel Split(AND).

step1 requires step2 and step3 in the "Then Go To" statement like as below.

And step4 requires Rendezvous(AND) as Pre-conditions.

Matching Join Type for Parallel Split is Rendezvous (AND).

I hope it is helpful for your investigation.

Regards,

Shoichi

Hi Shoichi, 

Thank you for your input which is really helpful.

When I add the conditions below if the fields are NULL, it should go to the different step and finish the job. This is where I am exactly facing the issue. 

In addition, you mentioned that Pre Condition and Post Condition in Step 4 

When I go to the same step 4 i.e. (Sponsor & IT leader ) step, I dont have the option to set up the post condition. 

Hi Arun,

I may not understand your issue correctly.

I feel you want to know about "Decision Point(XOR)" and "Merge(XOR)".

So, I modified sample process which I use in my previous reply like as below.

I added step0 at the front of step1.

step0 checks if the field is null. If field is null, then it go to finish step. If field is not null, then it go to step1 step.

step0 details:

finish step details:

I run this process with field = null.

start->step0->finish steps were executed like as below process flow diagram.

I run this process with field != null.

start->step0->step1->step2->step3->step4->finish were executed  like as below process flow diagram.

Regards,

Shoichi

Hi Shoichi, 

Step 0 -> you have provided the "Post Condition" as "Decision Point (XOR)" 

Consider this as my "Architectural Group"  as a "Step 0". I dont have an option to put the Post Condition here under "Architecture Group". I have 

Hi Shoichi, 

Thank you for the input.  Here is the process workflow diagram that built using the "Decision Point (XOR)"

Under - System Check for Approvers -> I had three conditions 

If the fields are full -> It should go to Missing Attributes. 

If Arch Group is NOT null -> It should go to Arch Approval

If Service Group is NOT null -> It should go to Serv Approval

But the above workflow works for only Missing Attribute and Service Approval 

Please do let me know your thoughts and inputs

Hi Shoichi, 

I built the same as you mentioned but I have the decision XOR and Parallel split now. But it is not going to the "Project Incomplete - Missing Attribute" instead it goes to the Shared Services Approval when the fields are null.

Below is the condition for System Checks Approval 

It goes here straight rather than going to Missing Attributes

Any thoughts on this ?

Please have a look at this topic How to create a process to check if a field is null  - it indicates a Look-up (which I believe you are checking on), will not work for NULL.

Hi Roland 

If Group 1 -> Approves, Group 2-> Rejects, it should go to "Rejected" and finish the job but It goes to Phase Rejected and Group 3 Approval which is NOT Correct. It should go to only "Rejected" and finish the job. Any thoughts 

I was referring to your first decision point and explaining why it may not work with null.  Have you resolved this one?

In relation to your latest process flow diagram, you need an earlier merge point, and if any of the groups reject it, it goes to the rejection path, otherwise it goes to the 3rd group which if they reject it, assumable would go the rejection path as well ( this is not in your process flow).

Note, you are being very piecemeal in your development.   Your screen shots of the process flow are very different from when you asked your first question.  Wasn't this documented up and agreed upon prior to you writing this process?

Hi Roland, 

I was able to fix the Null values and thanks for your input

I am trying to work on the sample before I get into the actual requirement. 

Even if I introduce Merge earlier, it ends up with "Un-Matched" split join pair found. I tried "Merge & Wait" after the "Phase Rejected" but it is still going to the Group 3 Approval. I am not sure what will be the logic that I need to introduce here to achieve the result. 

Hi Arunchalam,

You have some problems in your logic because of the fact you are using a multi-threaded option (Parallel AND or Multi-choice OR) as one of your splits.  XOR is single-threaded.  This means that no matter how many splits and joins there are you can only take one path through the process, you can never go down more than one path.  Your multi-threaded options can go down one or more of the paths you create. 

In the case of Parallel AND all paths will be followed and completed (not necessarily at the same time). 

In the case of Multiple Choice (OR) one or more paths must be completed.  You have three choices of merge type.  Wait and Merge has the same end result as Rendevous AND because all paths must be completed before you will be allowed to move to the next step.  First in Line will allow you to move to the next step as long as at least one path has completed.  Other paths may or may not be completed later.  But, they will not affect the overall process flow.   You can think of the Mult-Thread option as having no synchronization.  The next step starts when the first incoming thread completes.  Other threads will create a new copy of the next step when/if they complete.

XORS because of the fact they are single-threaded are very forgiving.  You can take a step from one branch and point it to a step in a different branch of the process and have everything work without a problem.  Branches from the same split point can end in different merge points.  You can do almost anything you want as long as you are only using XORs and Merge XORs.  This is what most people do most of the time.  XOR processes will sometimes validate when you do not have the same number of splits and joins.  However this may be problematic later.

Multi-threaded processes are a whole different story.

- All branches coming out of a single split must end at the SAME merge point.

- Steps must point to another step in the same branch.  They cannot point to a step in a different branch.

- Nested splits must join before the parent split can join.  Even nested XORs should follow these rules.

- You must have the same number of splits and joins.

I have reconfigured your process to follow these rules.  Notice that I had to duplicate some of your steps and create dummy steps that do nothing but act as a merge point.

Also, like Roland, I noticed that your Group 3 Approval step does not have an option to approve or reject in either thread.

If you are still having problems with your process not going down the correct branch, it probably has something to do with your post condition(s).

I hope you find this information helpful.

Jeanne

Hi Jeanne, 

Thanks. This is really helpful.

In addition, Group 3 also approves. If Group 1 & Group 2 approves only, it should go to Group 3. If Group 1 or Group 2 rejects, it should NOT even go to Group 3 and finish the job. 

Assuming that this requirement is still valid:

Why do you even have a split to two separate Action items?  Couldn't one Action Item be sent to both groups (aka CS Group and Arch.Group in the same Action Item), and if that Action Item is 'approved', then it goes to Group3?

Hi Roland, 

I am NOT sure how to use the same Action Item for both groups and hence I have used the separate "Action Item". 

Hi Roland,

This would be a much better way to go assuming the following:

- the action item is being sent to only two individuals (not two groups of people)

- the wording is the same in both approval action items

If he is sending it to two groups of individuals, I can't think of a way to ensure he is getting at least one response from each of the two groups before moving to the next steps.  Can you?

@Arunchalam:  If this would meet your needs, let us know and I will explain.

Jeanne

Jeanne_Gaskill_CA_Clarity_Support

I agree with Jeanne, it goes to two different groups. I have a question here in the above diagram 

Why do I need to keep Group 3 Approvals 2 times?

For example:

Group 1 and Group 2 - Approves -> Go to Group 3 Approval (Action Item to Approve or Reject) -> If Group 3 Approves, I am setting the project stage to the next level. If Group 3 Rejects, it will send the notification to the particular group that this has been rejected and project stage will be reverted to the original. 

If any one in Group 1 or Group 2 rejects, it should directly go to the "Rejection" phase and set the Project Stage to the previous stage. 

The stage that am struggling is that it should not even go to "Group 3 Approval" and I would need some guidance here how to achieve it. 

Jeanne_Gaskill_CA_Clarity_Support, roland.parrotte

Thank you Jeanne and Roland. I was able to completely build the sample workflow and actual development is also completed by using the above tips. 

Glad you got it sorted.  Can you post the working Process Flow Diagram - would be interested in seeing the end result, and for those who also look at this topic in the future.

Hi Roland, 

Sure. Will do it.