Hierarchical Relationships

Microsoft Dynamics 365 and the Power Platform

Now that we understand Relationship Behaviours, let’s explore Hierarchical Relationships in this step.

You can gain valuable business insights by defining and querying hierarchically related data. The hierarchical modelling and visualisation capabilities give you a number of benefits:

• View and explore complex hierarchical information.

• Build and analyse aggregated information, e.g. key performance indicators (KPIs) or company turnover, in the contextual view of a hierarchy.

• Query hierarchical data for reporting and development purposes.

Some standard entities in Common Data Model already have hierarchies defined. Other entities, including custom entities, can be enabled for a hierarchy and you can create the visualisations for them.

The option to define a hierarchical relationship is only available for self-referential relationships. A self-referential relationship is a 1:N relationship between an entity and itself where the same entity is defined as both a primary and a related entity.

For example, Project within your organisation may have a number of sub-projects included, each with an independent set of data. By defining the self-referential relationship for the Project entity, you define a data structure where a project can have a parent project and sub-projects thus creating a hierarchy.

Once the relationship is defined, you can declare it as hierarchical by setting Hierarchical option to Yes using the relationship properties window in the classic solution explorer. The following limitations apply:

• Some of the out-of-the-box (1:N) relationships can’t be customised. This will prevent you from setting those relationships as hierarchical.

• You can have multiple self-referential relationships, but only one relationship per entity can be defined as the hierarchical relationship.

Once the hierarchical relationship is defined, and a record is part of the hierarchy, users will be able to select View Hierarchy option in the model-driven apps when the record is selected.

Hierarchy view uses Quick View forms that are part of the solution to visualise individual records. If more than one Quick View form is available, users will be able to switch using the form selector.

Creating a hierarchy adds new customisation capabilities:

• Create rollup fields utilising the hierarchy. For example, you can create a Total Budget rollup field for the Project entity that will include the sum of all budgets for all sub-projects under a record in the hierarchy.

• Build views and processes that query the data using Under/Not Under logic exposed in Advanced Find and the workflow editor.

Removing Hierarchy

Once you set Hierarchical property, rollup fields, processes and views can be configured to depend on this property. If you set Hierarchical option to No to remove hierarchy from the relationship, later on, those capabilities that depend on the hierarchy will not work.

Additional Considerations

Some of the out-of-box (1:N) relationships cannot be customised. They provide a specific behaviour and function in the application. Because of this fact, you are not able to set the relationship as hierarchical. A new self-referential relationship would need to be created and then defined as hierarchical.

Hierarchy and visualisation are limited to one entity only, e.g. you cannot show accounts and contacts in the same visualisation.

Next up, we focus on Other Entity Options.

 

How to remove GUID from folder name in Dynamics 365 CRM and SharePoint integration

 SharePoint Security Sync enables you to create custom document library structure in SharePoint and also 
customize the record folder name which is quite helpful for data storage and management in a smart way!

Introduction

Recently we had a requirement from a client, they wanted to remove the GUID appended to the folder name.

There is a hidden way to achieve this. It is stored in an OrganizationSettings, though they have not exposed a way on a UI to update this, however, this can be done programmatically.

Please follow this blog to understand the approach.

Default structure of SharePoint folder name (PrimaryFieldName_RecordGUID)

To change the default behavior of the folder name we need to update CreateSPFoldersUsingNameandGuid property of organization to false.

Kindly follow the below steps to do that:

Below is the code snippet which I have tried from console application(c#) (if you want you can try with plugin/custom assembly as well) –

Entity orgEntity = new Entity("organization");

orgEntity.Id = new Guid(“46f31389-4d7d-43d7-b347-fae0d47f8b7f");

orgEntity["orgdborgsettings"] = "<OrgSettings><CreateSPFoldersUsingNameandGuid>false</CreateSPFoldersUsingNameandGuid></OrgSettings>”;

_crmhandler.UpdateRecord(orgEntity);

To get the organization ID, refer to below screenshot –

Now when SharePoint folder will be created then it will contain only name not GUID.

Conclusion

We can easily get rid of GUIDs in SharePoint folder name by changing Org setting.

Also applied for normal file creation without guid.