Coupling and Cohesion or

When to create table relationship and when to use Connections.

What the… has Couple and Cohesion got to do with CRM I hear you ask.  Well, I’m glad you did.  Let’s start with a basic software engineering definition. 

Coupling refers to the degree of interdependence between modules and

Cohesion refers to the degree in which elements within a module work together to fulfill a single. Well defined purpose.

Ok, but what does that mean in relation to Dynamics CRM?  When we talk about Coupling in CRM, we are really talking about the number of relationships created between entities (Tables) and when we talk about cohesion, we are really talking about what we store in an entity or table.

Great, that’s cleared that up.  So, what does it really mean?  Let’s look at a simplified example.

The fictious car company, Better Faster Cars (BFC).  They manufacture and sell cars to global network of dealers.  In their organisation, the sales team is split up into various teams who all have a roll to play in feeding information back to the manufacturing team to help improve delivery schedules, quality improvements, feature improvements and more.  They also have a team of Quality engineers that also feed information back to the manufacturing team.  The Executives, take a keen interest in the profitability of BFC and they too, feed information back to the Manufacturing team to assist in streamlining the process.  The dealers, guess what, they too send information back to the Manufacturing team about service issues, warranty issues and customer feedback.  You get the idea.  There are lots of people and teams all taking to the Manufacturing team.

There are two ways we can model this in CRM.  We could map each of the user interactions with the Manufacturing team as a named relationship.  In the table below we’d have 14 separate table relationships between the user table and the manufacturing table

Dealer Sales Feedback (USER)	Many to one relationship	Manufacturing
Delivery Updates (User)	Many to one relationship	Manufacturing
Quality Sign Off Exterior (User)	Many to one relationship	Manufacturing
Quality Sign off Engine (User)	Many to one relationship	Manufacturing
Quality Sign off Interiors (User)	Many to one relationship	Manufacturing
Quality failure Notification (User)	Many to one relationship	Manufacturing
New Feature Request (user)	Many to one relationship	Manufacturing
New Model Request (User)	Many to one relationship	Manufacturing
Executive Sign off	Many to one relationship	Manufacturing
Executive budget sign off (user)	Many to one relationship	Manufacturing
Dealer Warranty Claim (User)	Many to one relationship	Manufacturing
Deal Model Spec Change Request (user)	Many to one relationship	Manufacturing
Exec team change request sign off (User)	Many to one relationship	Manufacturing
Exec Team Model change sign off (User)	Many to one relationship	Manufacturing

 On way to think of relationships between entities or tables is like doorways that you can pass information through, but you need to have a door for each type of information you want to pass through it or one door for each person who is going from one room to the other.  If we change the analogy slightly and think about rooms in different buildings and we use bus to move the individuals from room to room.  1 individual 1 bus.  Not the most efficient way to do it.  That’s not to say that it is wrong to do this.  There are other ways to do it, that are easier to manage, easier to read and do not require all those relationships to be created for every single record, regardless of if they are used or not. 

This method is known as Coupling, the higher the number of relationships the higher the coupling.

Side Note

We not going into the merits of software design here, merely trying to highlight the difference between to ways of implementing a solution.

CRM / D365 comes with a very neat feature called ‘Connections’ is a cleaver way to join entities, on the fly, without having to go and create your own set of entity relationships.  What’s more, you can join almost any entity with any other entity.  We can take advantage of this feature to simplify our model. 

Here’s how.  To use Connections, you first need to create some ‘Roles’.  A ‘Role’ is really the name of the relationship.  For example, we could create the following roles:

·         Approves Update Request

·         Requests Feature Update

·         Approves Feature

·         Requests Warranty approval

·         Approves Quality check

In order to use the connections, you’ll also need to add a table (sub grid) on the form of the entity you want to see them and set up some permissions and complete the configuration steps, but once you have then you can start adding the data as you have it.

To try and put that into context.  If you are entering the data on the manufacturing entity, you receive a request for a warranty claim, you go to the grid, click on add new connection,  select the user who (from) made the request,, select the connection type (role) for example  ‘Requests Warranty Approval’ and then add the some details in the description box and save it. As more requests or approvals come in you can add more connections.  Anyone viewing that record can easily see all the connections.

Now if we go back to the question, Relationships or Connections?  The answer depends, like always, on what you are trying to achieve.  I personally would suggest that if you have many relationships from to a two a single entity, it is a candidate for using connections.  Furthermore, Connections are great for when you want to join entities together for a given interaction or reason.  For example. If you have multiple companies that you are working with on a project and each company is providing a different service  and also provides the same or other services to other companies and projects,  building a set of relationships to capture all the potential combinations would be a nightmare, and messy!  But, if you use Connections, you only have to define the relationship roles then you can just select the two entities and select the role (what they do) that joins them.  Connections are particularly useful when you want to capture information about a contact who acts in different roles for different clients or projects.

Connections, if you haven’t guessed are more in line with Cohesion, because they take care of the relationship building inside a virtual black box that the user (designer) doesn’t have to worry about.