DocMan supports a definition of a Parent Map for each Dynamics Entity we want to integrate with SharePoint.

This Parent Map allows us to define the Folder or Document Location for a child record (say a Contact) in relation to a parent record (say the Company associated to that Contact), so we can benefit from the Hierarchical nature of SharePoint for managing our Documents.

But what if we have the scenario where a Record could have several different types of Parent?

If we take the example of a Custom Entity added to Dynamics for a ‘Decision’ and that this Decision could have a Child-to-Parent relationship with a number of other entities:

• The Decision could be linked to a Parent Investment
• Alternatively, the Decision could be linked to a Parent Agenda Item
• Or the Decision could be linked to a Parent Action

This would involve either the Decision being defined as a Custom Activity Entity in Dynamics with the Regarding Object relationship that can relate to many different types of Entity – in which case, DocMan can handle this in the way we handle other types of Activity.

But if Decision is not a Custom Activity Entity then we will find ourselves with 3 different Relation / Lookup Fields in Dynamics:

• Lookup to Investment
• Lookup to Agenda Item
• Lookup to Action

And we need DocMan to read the right Relationship to determine which should be used as the right Parent Record Type for the Decision.

To do this, we need multiple Parent Maps for our Entity.

We can configure this arrangement in DocMan by browsing to the DocMan Configuration Area, into the Entity we want to configure, and then stepping through the following steps:

1. Remove the Primary Parent Map - First of all, removing the Default Parent Map field so this is blank.  This removes the idea of a Primary Parent Map in favour of a decision tree for which Parent Map to use for a Decision.

2. Multiple Parent Maps – each Entity Definition in DocMan has a number of Maps or Rules connected with that Entity.  In this list, we can add multiple new Parent Maps, one for each Relationship/Lookup Field in CRM that we want as a potential Parent Relationship.

Here we can add Mappings to define the logic for how we want the Entity to behave based on the Fields populated in CRM.

3. Add Additional Parent Maps – We can add new Maps here to define what Lookup Fields will be examined and which Entity to then Lookup to.

This then defines our logic which we can test by adding Decisions to Dynamics.

4. Decision connected with an Investment – where we have a Decision linked to an Investment, this then adds the Folder to store Documents on the Decision to the existing structure defined for that Investment Record:

/sites/dynamics365docs/Investments/abraaj financial technologies holdings limited/Decision C

With the bold portion of the SharePoint Address being derived from the Investment, and the final Folder from the Decision.

5. Decision connected with an Agenda Item – where we have a Decision linked to an Investment, this then adds the Folder to store Documents on the Decision to the existing structure defined for that Investment Record:

/Management Committee/Committee Documents/2019/mc-25-2019/05.00 - crm training/Decision for Agenda Item

This allows the same Entity Type in CRM to hook into different SharePoint structures depending on the Type of Parent Record involved – and can be useful for keeping our Documents well organised for types of records that may be related to multiple types of record in CRM.

This can work well in environments where we have multiple SharePoint Sites or even different SharePoint Instances as doubles up with DocMan’s ability to connect more than one SharePoint Site into Dynamics.