Become a Dynamics 365 expert with Syvantis Learn
Provide additional details about the offer you're running.
This store requires javascript to be enabled for some features to work correctly.
Provide additional details about the offer you're running.
Relationships Demystified in Dynamics 365 CRM
Dynamics 365 Sales
Relationships in Dynamics 365 CRM connect records so information can be organized, navigated, and reported on more effectively. This Fast Class explains the two primary relationship types, many-to-one and many-to-many, and demonstrates common variations including traditional lookup relationships, hierarchies, Regarding fields, activity parties, classic many-to-many relationships, and bridge relationships such as Connections.
Understanding Relationships in Dynamics 365 CRM
Relationships create links between records and help organize data within CRM. Some relationships are available out of the box, while others can be added to better reflect your organization's processes. If you've worked in CRM, you've already encountered relationships through features such as lookup fields, related lists, and subgrids on forms. There are two primary types of relationships:
Each type can appear in several different ways throughout Dynamics 365.
Understanding Many-to-One Relationships
Many-to-one is the most common type of relationship. A standard many-to-one relationship connects two different record types. It's typically represented by a lookup field on the "many" side and a grid or list on the "one" side. A traditional example is Contacts and Accounts. One Account can have many Contacts, while each Contact can be associated with one Account. On an Account form, you can see associated Contacts in a subgrid. On the Contact record, the Account Name lookup establishes the relationship with the Account.
Creating Related Records
You can establish a relationship by creating a Contact and selecting the appropriate Account in the Account Name lookup field. An easier approach is to create the Contact directly from the Contacts subgrid on the Account form. When you create a Contact this way, the Account information is automatically populated for you. Other information, such as the business phone number and address, can also populate automatically through relationship mappings. The default mappings can be changed by your CRM administrator.
Using Hierarchies
A hierarchy is another form of many-to-one relationship, but instead of connecting two different types of records, it connects records from the same table. Parent and child Accounts are a common example. You might have a parent Account representing a company's headquarters and child Accounts representing individual locations. On a child Account, the Parent Account lookup establishes this relationship. This allows Dynamics 365 to represent organizational structures while keeping each location as a separate record.
Using the Regarding Field
Regarding is a special type of many-to-one relationship. A standard lookup typically searches for one type of CRM record. The Regarding lookup can search across several different record types. It's commonly used with CRM activities such as:
When you create an activity from a record's Timeline, Dynamics 365 can automatically populate the Regarding field with that record. Once the activity is saved, it appears in the record's Timeline. Depending on the records enabled in your CRM application, the Regarding field may allow you to connect the activity to records such as Accounts, Campaigns, Cases, Contacts, Knowledge Articles, Leads, and Opportunities.
Understanding Activity Parties
Activity parties, sometimes referred to as party lists, are another specialized type of relationship associated with CRM activities. A familiar example is the To field on an email. Unlike a standard lookup where you select one record, this field allows you to add multiple recipients. Those recipients can also represent different types of CRM records, such as Contacts, users, and Leads. The CC and BCC fields work in a similar way. This allows a single CRM activity to involve several participants while keeping those relationships associated with the activity.
Understanding Many-to-Many Relationships
Many-to-many relationships connect multiple records on both sides. Instead of one Account having many Contacts while a Contact points to one Account, a many-to-many relationship allows multiple records on one side to be associated with multiple records on the other. Dynamics 365 supports two common forms of many-to-many relationships:
The main difference is how much information CRM can store about the relationship itself.
Classic Many-to-Many Relationships
A traditional example of a classic many-to-many relationship is Contacts and Marketing Lists. A Marketing List can contain many Contacts, and one Contact can belong to many Marketing Lists. Unlike a traditional many-to-one relationship, this relationship doesn't use a visible lookup field. Instead, you work with records through related grids. Behind the scenes, Dynamics 365 establishes the association using a hidden database table known as an intersect entity. For example, you can open a Marketing List and use its Members area to add Contacts. On the Contact side, you can use the Related area to see the Marketing Lists associated with that Contact. This provides the relationship between the records, but it doesn't provide much additional information about why they're related.
Using Bridge Relationships
A bridge relationship addresses that limitation by giving you a record representing the relationship itself. A bridge creates a many-to-many relationship by using many-to-one relationships in both directions. Unlike the hidden intersect entity used by a classic many-to-many relationship, the bridge record is available in the database and can contain additional information describing the relationship. A common Dynamics 365 example is Connections. Connections can link records together while also telling users something about the nature of that connection.
Using Connections on Opportunities
Connections are commonly used with Opportunities to identify stakeholders and other people involved in the sales process. For example, adding a Contact to an Opportunity can establish that person as a stakeholder. You can then open the Connection record and provide more information about that person's role. If the Contact is responsible for making the purchasing decision, you could identify that person as a Decision Maker instead of simply a generic stakeholder. The Opportunity can then show people and their roles, giving everyone working on the Opportunity more context about who's involved in the potential sale. Organizations can also modify available Connection roles or create new ones that better reflect their processes.
Choosing Relationships That Support Your Processes
Relationships do more than connect records behind the scenes. They determine how information is organized and presented to CRM users and can affect how that information is used for reporting. Many-to-one relationships can connect records through standard lookups, organize records into hierarchies, and connect activities through specialized functionality such as Regarding fields and activity parties. Many-to-many relationships allow multiple records to be connected on both sides. Classic relationships provide a straightforward association, while bridge relationships give you the ability to store additional context about why those records are connected. Understanding these relationship types can help you better interpret the information already available in Dynamics 365 and identify new ways to organize CRM data around your business processes.
* This transcript summary has been generated from the Fast Class video by Microsoft Copilot. The Fast Class itself was prepared and taught by Syvantis expert consultants.
TUNE INTO THE LIVE CLASS
Ask your questions and get real-time responses from your trusted Syvantis consultants.
What's on the schedule?
Dynamics 365 Business Central
Dynamics 365 Sales (CRM)
Dynamics 365 Customer Insights
Power Platform
Keep learning...
Business Process Designers. Technical Experts. Dedicated Partners.