What happens if two customizers modify the same entity in Dynamics CRM 4?

[In addition to blogging, I am also now using Twitter for quick updates and to share links. Follow me at: twitter.com/pabloperalta]

Depending on the size / timeframes / requirements or even particularities of your project, you may need that two or more team members customize simultaneosly the same entity. For instance, you may require that one member works on the entity form while other member sets up views.

Other scenario could be finding yourself (or one team member) customizing an entity while at the same time other people is also customizing the same entity or is attempting to do so, without consciously knowing that.

In any case, you are in a usual situation if you are accustomed to source control as it's the case of working with .Net against TFS, VSS, SVN, etc. Nevertheless, neither the concept of solution nor the concept of source control apply to Dynamics CRM 4 customizations (some great improvements are coming on version 5 but not for version 4).

I made some research and didn't find an answer, hence decided to try it by myself and share the results. So, here are the results I found out classified by scenario:

Scenario 1: Two customizers working on the same element (i.e. form) after first customizer saves his/her work...

In this scenario, two customizers open the same entity at the same time for making changes to an existing element. Account Main Form is taken for this sample. Customizer 1 removes a field and saves the form. Afterwards (just some seconds later), Customizer 2 opens the same form (remember the entity definition window was opened previously any change has been made to the form). The process is depicted below:

1. Customizer 1 removes field 'Other Phone' from form..

2. Customizer 1 saves the form..

3. Customizer 2 opens the form after Customizer 1 saved it..

In conclusion, in this scenario when customizer 2  opens the form he/she gets the latest version of it, which includes the changes made by customizer 1 (despite entity definition window was opened before any changed has been made to the form). I could also check this out for views, attributes and relations and the same rule applies meaning that if somebody makes any change to an existing element on an entity, saves it and then any other person opens the element to work with it, he/she gets the latest version of it.

Again, this is true as far as customizer 2 opens the element after customizer 1 saves it.

But..., what happens if customizer 2 works on the same element but opens it before customizer 1 saves his/her changes? ... Let's get through this case, by each type of element on an entity...

Scenario 2: Modifying the same view...

In this scenario, two customizers (probably accidentally) open an entity for making changes to the same view (Account Advanced Find View in the sample). They take exactly the same version of the view and each one adds a different field to it. The second customizer saves his/her work after first customizer. The process is depicted below:

1. Customizer 1 adds field 'Account Number' to view.

2. Customizer 1 confirms the field and saves the view...

3. While all of the above was happening, Customizer 2 adds field 'Account Rating' to view.

4. Customizer 2 confirms the field and saves the view (just some seconds after Customizer 1 pressed on Save)...

5. Final result:

 

In conclusion, in this scenario applies the rule 'last customizer wins'. When opening the view for customizing again we see that the changes applied came from customizer 2 (who saved his/her work later), while earlier changes done by customizer 1 were totally replaced.

So, be careful: there are no warnings, nobody realizes about this situation. 

Scenario 3: Modifying the same form...

In this scenario, two customizers (probably accidentally) open an entity for making changes to the main form (Account Form in the sample). They take exactly the same version of the form and each one adds a different field to it. The second customizer saves his/her work after first customizer. The process is depicted below:

1. Customizer 1 adds field 'Account Rating to main form.

 

2. Customizer 1 confirms the field and saves the form...

 

3. While all of the above was happening, Customizer 2 adds field 'Email Address 2' to form.

 

4. Customizer 2 confirms the field and saves the form (just some seconds after Customizer 1 pressed on Save)...

 

5. Final result:

 

In conclusion, in this scenario also applies the rule 'last customizer wins'. When opening the form for customizing again we see that the changes applied came from customizer 2 (who saved his/her work later), while earlier changes done by customizer 1 were totally replaced.

So, be careful: there are no warnings, nobody realizes about this situation.

 

Scenario 4: Attempting to add the same custom attribute to an entity...

In this scenario, two customizers (probably accidentally by a discoordination) open an entity for adding the same attribute (mycustomattribute in the sample). They take exactly the same version of the entity and each one tries to add an attribute with the same name. The second customizer saves his/her work after first customizer. The process is depicted below:

1. Customizer 1 adds field 'mycustomattribute' to entity.

2. Customizer 1 saves the field, hence the attribute creation is triggered...

 

3. The attribute is successfully created and displayed on 'Attributes' list on Customizer 1 machine..

 

4. While all of the above was happening, Customizer 2 was attempting to create the same attribute...

 

5. When Customizer 2 attempts to save the attribute, the following validation error occurs:

So, in conclusion, in this scenario, despite both customizers started to work with the same version of the entity, when customizer 2 attempted to create the attribute with the same name customizer 1 saved it eariler, a validation error arised warning about the existence of that attribute and hence, no attribute is created except a different name is used. 

In fact, when customizer 2 refreshes his/her list of attributes the new attribute created by customizer 1 is displayed:

 

Scenario 5: Editing the same attribute on an entity...

In this scenario, two customizers (probably accidentally by a discoordination) open an entity for editing the same attribute (mycustomattribute in the sample). They take exactly the same version of the attribute and each one tries to adjust its maximum lenfth. The second customizer saves his/her work after first customizer. The process is depicted below:

1. Customizer 1 edits the Maximum Length property of the attribute 'mycustomattribute' :

 

2. Customizer 1 saves the changes and hence, attribute update process takes place..

 

3. While all of the above was happening, Customizer 2 was modifying the same property of the same attribute:

 

4. After customizer 2 saves his/her work, no validation error is triggered. Instead...

5. Final result: last wins. The changes applied were from customizer 2.

 

In conclusion, contrary to attribute creation (scenario 4) in this scenario, when modifying an existent attribute applies the rule 'last customizer wins'. When opening the attribute for customizing again we see that the changes applied came from customizer 2 (who saved his/her work later), while earlier changes done by customizer 1 were totally replaced.

So, be careful: there are no warnings, nobody realizes about this situation.

 

Scenario 6: Attempting to add the same relationship to an entity...

In this scenario, two customizers (probably accidentally by a discoordination) open an entity for adding the same relationship (Accounts-Sales Literature [1:N] in the sample). They take exactly the same version of the entity and each one tries to add the relationship with the same name. The second customizer saves his/her work after first customizer. The process is depicted below:

1. Customizer 1 adds the relationship Accounts-Sales Literature [1:N] and name it as suggested by default, new_account_salesliterature:

 

2. Customizer 1 saves the new relation, so triggering the relationship creation process:

 

3. While all of the above was happening, Customizer 2 was attempting to add exactly the same relationship with the same name:

 

4. But, when Customizer 2 attempts to save the new relationship, the following validation error arises (similar to scenario 4 when trying to create the new attribute):

 

So, in conclusion, in this scenario, despite both customizers started to work with the same version of the entity, when customizer 2 attempted to save the new relationship with the same name customizer 1 saved it eariler, a validation error arised warning about the existence of that relationship and hence, no relationship is created except a different name is used.  

This behaviour is pretty similar to when creating new attributes as depicted on scenario 4. In fact, here if we refresh the list of existent relationships, the new one created by customizer 1 appears on the list.

 

Scenario 7: Editing the same relationship on an entity...

In this scenario, two customizers (probably accidentally by a discoordination) open an entity for editing the same relationship (the above created, fictitous Accounts-Sales Literature [1:N] relationship). They take exactly the same version of the relationship and each one tries to adjust the Type of Behavior and Display Order properties. The second customizer saves his/her work after first customizer. The process is depicted below:

1. Customizer 1 edits the 'new_account_salesliterature' 1:N relationship (remember this is a fictitous relationship we created on the previous scenario). Customizer 1 sets the Type of Behavior property to 'Referential, Restrict Delete':

 

2. Customizer 1 saves his/her changes and the 'Updating relationship' message cames up ..

 

3. While all of the above were happening, customizer 2 was modifying the same relationship. Customizer 2 set Type of Behavior to just 'Referential' and changed the Display Order property to '20,000':

 

4. When customizer 2 presses on Save, contrary to prior scenario, no validation error is displayed but just 'Updating relationship' message comes up on the screen:

 

5. Final result (again, last wins):

So, in conclusion, contrary to relationship creation (scenario 6) in this scenario, when modifying an existent relationship applies the rule 'last customizer wins'. When opening the relationship for customizing again we see that the changes applied came from customizer 2 (who saved his/her work later), while earlier changes done by customizer 1 were totally replaced.

So, be careful again: there are no warnings, nobody realizes about this situation.

 

Conclusions

• If a customizer opens an existent object to work with (i.e. form, view, attribute, relationship), he/she always gets the latest version of it, including any change recently made by other customizer, even if the former customizer opened the entity definition window prior to those modifications (this does not matter at all). [scenario 1]

• If two or more customizers open the same view to make changes, the 'last wins' rule applies. There is no conflict detection, no merge, no warning message. Just last wins. [scenario 2]

• The same rule applies when making changes to the main form and other elements in fact. Again, 'last wins' rule applies without any conflict detection, merge, or warning message. Just last wins. [scenario 3]

• If two customizers attempt to add an attribute with the same name, a validation error will be displayed avoiding any conflict. No matter that both started to work with the same entity version, with the same list of attributes. If customizer1 created an attribute which is not present yet on customizer2's list, if the latter attempt to create the same attribute he/she won't be able to do that.  [scenario 4]

• Contrary to the above, if two or more customizers make changes to an existent attribute, the 'last wins' rule applies. As it's the case with other elements, there is no conflict detection, no merge, no warning message. Just last wins. [scenario 5] 

• Regarding to relationships, they work in a similar way attribute do. If two customizers attempt to add a relationship with the same name, a validation error will be displayed avoiding any conflict. No matter that both started to work with the same entity version, with the same list of relationships. If customizer1 created a relationship which is not present yet on customizer2's list, if the latter attempt to create the same relationship he/she won't be able to do that.[scenario 6]

• Contrary to the above (and similar to attributes), if two or more customizers make changes to an existent relationship, the 'last wins' rule applies. Again, there is no conflict detection, no merge, no warning message. Just last wins. [scenario 7]

Hope this help,

PP

 [In addition to blogging, I am also now using Twitter for quick updates and to share links. Follow me at: twitter.com/pabloperalta]