If we take the scenario where we want to have a SharePoint Site per Business Unit that we have in Dynamics, we can model this using DocDrive365 in the following steps:

STEP 1 – Model the SharePoint Structure for how we will handle Business Units

Add a Site per Business Unit Rule into the DocDrive365 Configuration for the Business Unit Entity.

For security, we can configure each Business Unit Site to have its own Unique Permissions.

If you have access to our Demo Environment, click here to see this rule.

This leads to a new SharePoint Site for each Business Unit we add to Dynamics:

As we switched the [Inherit Permissions] to ‘Unique Permissions’, this means that each SharePoint created for a BU has its own set of permissions – rather than simply defaulting to the permissions of the Parent Site.

This allows us to start defining the permissions we want in SharePoint to match those we define for Dynamics.

STEP 2 – Define the Security

If we want to model a simple security system where each Business Unit Site is only available to the Users in that Business Unit, we can do this in a simple set of steps.

• Each Business Unit in Dynamics automatically maintains a Team containing all the Users assigned to that Business Unit (this is part of the base functionality in Dynamics), we are going to use this Team to define who has access to the SharePoint Site for the Team.
• To put this to use, we first add a new Lookup Field from the Business Unit Entity to the Team Entity – so we have a point-to-point link from the Business Unit to the Team that we can draw on.
• We can add a DocDrive Dynamics-to-SharePoint Security Rule to add the Team connected to the Business Unit as a Group in SharePoint with access to the Site for that Business Unit.

If you have access to our Demo Environment for this scenario, click here to see this rule.

The addition of the Security Rule connected to the Lookup field to the Team will then set the Security Permissions in each SharePoint Site created for each Business Unit.

We can see this in the SharePoint Site for either of our Business Units – most notably by clicking into Site Settings and into Permissions:

The SharePoint Site is shared with the France BU Group in SharePoint which is being synchronised with the France BU Team in Dynamics – this means that any Users added to removed to the France Business Unit will automatically be granted or removed from accessing the corresponding SharePoint Site here.

We can control the security from the Business Unit or Team in Dynamics:

And know this is fully integrated into SharePoint:

By default this means that each Business Unit has its own set of ‘Chinese Walls’ to prevent a User in Romania from being able to access Documents only intended for the French Business Unit and vice versa.

That sets up for the Sites approach to SharePoint – we can now look at how we put this to use.

STEP 3 – Model the SharePoint Structure for how we will handle Company Accounts

In our next step, we will see this in action for Company Accounts in these Business Units, and then look at sharing for when we might want to share Documents by Account for the BUs.

We can start by defining what type of Document Storage we want for each Company we add to Dynamics.

In this case, we can setup a simple set of Rules that:

• Parent Rule that places the Document Storage for a Company in the right SharePoint Site depending on the Business Unit for the Company.
• Bucket Rule that ensures a Document Library is present for ‘Client Documents’ in the SharePoint Site
• Record Rule that creates a Folder specifically for this Company in that Document Library

NOTE: For more information on these types of rules, this article on our site may be useful to explain how the Rules Engine in DocDrive365 is configured.

This gives us the following Account Entity Definition in DocDrive:

If you have access to our Demo Environment for this scenario, click here to see this rule.

This set of rules starts adding Folders to our SharePoint Sites on the basis of one Folder per Account Record in Dynamics.

Initially each Folder inherits the permissions defined for that SharePoint Site – and so grants access on the same basis:

• Users in our France BU have access to the Company Folders in their Business Unit
• Users in our Romania BU have access to the Company Folders for their Business Unit

Assuming we are logged in as a User in the Parent Business Unit who can see both BUs, we can see this from Dynamics to SharePoint:

The top 5 Accounts sitting under our France BU, and so appearing as Folders in the French SharePoint Site:

This gives us the basic level of dividing Documents by Business Unit so our SharePoint Security works in the same way as the Security we have in Dynamics.

STEP 4 – Share a Company with both France and Romania

Currently our Company Accounts are split 5 and 5 between our Business Units in a consistent model.

But, what if we want so share a Company between both Business Units?  Or we want to limit a particular Company to a smaller subset of Users?

We can do this by opening the Company in Dynamics and amending its sharing / permissions.

DocDrive provides a Grid control where this can be done manually, or we can build this into our Workflow for how User’s use Dynamics – in my case here, I’ve built a simple Workflow that changes the permissions for this particular Company.

Using the DocDrive Grid to share an Account in the French BU with both the French BU Team and the Romanian BU Team

We may not want our Users to have access to this type of sharing, so we may build this into our Workflow to trigger the sharing within our Solution’s Business Logic.

This can be done in Dynamic’s Workflow or using the DocDrive Custom Connector in Power Automate.

Either way – this setting of permissions via DocDrive triggers the following in SharePoint:

• The Folder for the Account is initially set to Inherit Permissions and so using whatever permissions the SharePoint Site is using for the Business Unit.
• As the permissions are set – this ‘breaks’ into Unique Permissions for the Folder
• The Unique Permissions being the permissions we have defined in the Grid or the Workflow
• In this case, sharing with both the FRA Team and the ROM Team to share out across both Business Units

This gives us certain Account Folders that are only visible to ROM, and other Account Folders that are only visible to FRA – but this Account Folder is in the middle of the Venn Diagram in being available to both Business Units. (but not to any other BUs that we may add, as its just the two initially)

We can see this in action by logging into Dynamics as an Example Romanian User – they now see their 5 Accounts + the 1 French Account that is now shared:

Our ROM User then also has limited rights within the France SharePoint Site – as per our rules, they do not have any rights over the Site or the Library, but they do now have rights to that particular Folder for that particular Account.

We can peek into SharePoint to see how these permissions have been replicated from Dynamics to SharePoint for our two Business Units:

The ROM User can see the Client Documents Library in the FRA Site but only sees the single Folder they have permissions to in this Library.

This sharing can then be easily reversed again in much the same fashion – either using the Grid and removing the Sharing, or having a 2nd workflow that does the same.

This can also be automated using DocDrive SharePoint Security Rules configured in the DocDrive365 App – but to keep this how-to to a manageable length, this will be detailed in a separate article.

What benefits does this give us?

In some ways, this is similar to the native Sharing System in Dynamics and Power Apps – just with the added benefit of replicating to SharePoint as well as Dynamics. (whereas by default, the security in Dynamics has not influence on SharePoint leaving permissions to be configured separately)

But by using Teams in Dynamics that are integrated as Permission Groups in SharePoint this gives us a number of benefits:

• DocDrive maintains a list of permissions in the custom ‘Permission Entries’ Entity – so we can always see or report on what is shared with who
• Permissions can be managed at the By-User level; but managing at the By-Team level makes for a much easier Governance Model – as any User removed from a particular Team then loses rights to all the SharePoint Locations that this Team granted them access for, and we never find ourselves having to remove individual permissions.
• Using the Automatic Teams that Dynamics creates for a Business Unit means that we have self-building Teams – so as a User may move from one Business Unit to Business Unit, the permissions are automatically set.  This can again help our security governance.
• Manual Teams can then be defined in Dynamics and used to have a consistent security model.

We’ve done extensive work helping clients integrate their SharePoint Security and Dynamics Security Models together – and so looked at many ways of making this possible with the easiest and best possible governance, and this approach of sharing-by-team is our best proposed way forward of solving the Dynamics-to-SharePoint replication problem and having a strong consistent and easily documented Security Model across both systems.

Further Reading

DocDrive365 Security Day One for getting started with Dynamics to SharePoint Permissions

https://www.crmcs.co.uk/content/docdrive365-security-day-one-getting-started-with-dynamics-to-sharepoint-permissions.aspx