Case-to-Case N:N workflow throws exception?

Jul 15, 2013 at 10:31 AM
This is a great plugin which will solve an immediate need my organisation has. Any help someone can give with the below would be MUCH appreciated!

I have a N:N relationship from Case to Case. This is so that I can have a case that is a parent of other cases.

I want to implement workflow that will update a field on the child cases when a workflow is triggered on the parent. When I do this I get the following error:

System.ServiceModel.FaultException'1[Microsoft.Xrm.Sdk.OrganizationServiceFault]:'Incident' entity doesn't containt attribute with Name = 'incidentidtwo'. (Fault Detail is equal to Microsoft.Xrm.Sdk.OrganizationServiceFault)

Any ideas?
Thank you
Jan 26, 2015 at 11:40 AM
Edited Jan 26, 2015 at 11:42 AM
Hey there,

I too have the same issue as described by Andrew .
I have it with an N:N relationship between Account and Account.

It seems that in order to manipulate, this tool differentiates between the two sides of relationship with the entityId attribute. Since in this issue - both sides of relationship are actually the same entity - the entityId is the same, so this tool for some reason is forcing an attribute of entityIdtwo in order to differentiate !!


Could this bug be fixed soon (this thread began 19 months ago) ??
I love the tool and it really helps a lot!

Thanx in advance,
Feb 8, 2015 at 12:11 AM
Hi Avi & Andrew - I can assure you that nowhere in the code there is the word "two". So I think that the 'incidentidtwo' comes from somewhere else, although I would not know where from. As to using the plugin with N:N relationships between the same entity (case <-> case, account <-> account) this is actually very tricky. I haven't tested it thoroughly, but I suspect that if you don't have a a condition that terminates recursion, the plugin can and will kill your system.

You run the plugin on Account A, which will trigger a workflow to run on Account B (since there's a relation from A to B) but this will likely trigger a workflow on A (because of the same relationship) and back to B, and back to A, and things spiral out of control.
Feb 8, 2015 at 11:08 AM

A. I actually run the workflow on Account B only when a 2 option field is changed on Account A (that is what triggers the workflow). Therefor no loop will happen.
B. The attributes 'entityidone' and 'entityidtwo' - are created by the CRM automatically when associating an entity to itself. These are actually the attributes for the relationship table in the SQL DB.

Maybe this blog may give a hint (sorry I'm no "Coder", so I don't really understand it).

Feb 8, 2015 at 3:09 PM
Edited Feb 8, 2015 at 3:32 PM
Hi Avi - I was testing this today and found a problem that was caused by a stack overflow when issuing a large number of workflows, which has now been fixed in the latest release. Could this be a cause of the problem you are observing? Not sure if you can test the latest release, but that would be appreciated.

Anyway, I also think that there might have been a logical flaw in my design when using N:N with the same entity, because the program first tries to figure out how the relationship is setup, determines the direction of the relationship, and then runs the workflows on the other side. This should not cause an error, but might not consider all the possible related objects.

Here is what I think: in the normal case when you have different entities E1 and E2, it figures out which one of the two entityid refers to E1 (say it's entitityidone), and then runs the workflow on all the E2 that are referred to by the other entityd (entityidtwo).

In the case when E1 = E2 (such as N:N between Account and Account), then entityidone obviously always refers to E1 (as does entityidtwo), so the program runs the workflows on all objects referenced by entityidtwo.

See the problem? If you have three accounts A, B and C, with the following three relationship:
entityidone=A - entityidtwo=B
entityidone=A - entityidtwo=C
entityidone=B - entityidtwo=C

When you run on A you trigger B and C, but when you run on B you only trigger C, and when you run on C you trigger nothing.

The latest release should be able to handle this scenario correctly.