3 Minute Features : Episode 3: Relationships

Relationships are difficult, will she go out with you? Are you good enough? Does he want to propose?

Those in CDS are a little less complicated, but only just.

My next 3 minute feature tries to give you an understanding of relationships

Episode 3: Relationships


First, lets explain a relationship

The simpliest relationship there is in the Common data service is account to contact An account can have 0, 1 or more contacts. You could infer properties of the contact to be the same as the account. This relationship in CDS is called a 1 to many relationship if you take the relationship from the prospective of the account.

From the contact, this is a many to one relationship, as many contacts will be associated with the same account. The same relationship, looking at the contact, would be a many to one relationship

If, and this is pretty standard, a contact may have a relationship to many accounts, you can create a many-to-many relationship. This way, a intermediary table holds two relationships between the two entities in question.

Going back to my solution, select my entity I have been creating and then relationships.

As you can see, there are already a lot of relationships. These are created for you as you created the entity and selected some options. Connected From and To for example is because we ticked the box to Enable connections on the entity.

Select Add relationship, then start with a Many-to-one. On the right hand side, you firstly need to select the related entity. As we are creating a many-to-one, where MyThing entity is the child, CDS will create a new lookup field on the child entity and give it a name and label both of which you are welcome to change

In the general section, this is the name of your relationship itself. The default is very long winded, so I would advise to shorten to something more useful.

Advanced options are where the relationship behaviour is defined. This is a set of options to automatically control the relationship. Parental is the default, but to understand what this means, lets look at all the options available in Custom

The first is Delete. If the parent entity is deleted, what do you want to happen to the child? Delete the child as well when the business logic does not need orphaned records (for opporunity and opportunity lines for example) . Remove link will just make the child link to the parent null. Restrict will prevent the parent from being deleted if there are active child records present.

The second is Share. The options here either share the child record with the same as who has just had the parent record shared with them (would work with account and opportunities for example), share only active records with them, share only those records owned by the owner of the parent record. None ensure that the share doesn’t get cascaded.

Reparent is next, this works exactly the same as share, either changing the owner on all, active or user owned or none of the child records.

Assignment works the same as share, if the parent record is assigned, do you want to assign all / active / user owned or none of the child records. This could work with tasks associated with cases.

Finally unshare, which is the opposite of share.

There are 2 standard options available to you as well, namely Referential and Parental.

Referential has Cascade None for each of the Assign, Share, Unshare and reparent but with Delete as remove link or restrict

Parental has Cascade All for all options, including delete.

A word of caution here, a child entity can have only 1 parental entity, where you can cascade sharing or assigning. If there are 2 relationships, you will have to decide which one is the one you would like to use to cascade logic.

Relationship configured, I will hit Done. The new relationship is highlighted in bold.

I will quickly create a many to many relationship. Here after selected the related entity, you get to enter a relationship name as normal (noting the physical table name) and the new entity name you would like to create to serve as your intermediary table. Not there are no behaviour options here.

Finally through the one to many relationship. This behaves the same as the many to one, but you are creating the lookup field on the child entity, which is the entity you select. You have the option to select behaviour type here as well.

Hit Save entity to commit your changes to your environment.

Going back to the solution, you can see it has automatically included the three entities I chose as related entities to my solution, as we are configuring them as well.

comments powered by Disqus
My views, nothing to do with anyone else
Built with Hugo
Theme Stack designed by Jimmy