Many sysadmins choose to store CRM documents in SharePoint because managing documents is more intuitive in SharePoint. SharePoint also has very convenient extra functionalities for the end-users such as checking documents out and version history.
Another reason to go for this combination is that data storage is cheaper on the SharePoint side. If the standard SharePoint storage of 10 GB is not enough, you can buy extra storage at the very reasonable price of $0.20/month per GB extra.
Microsoft Dynamics 365 offers standard out-of-the-box integration with SharePoint that enables organizations to link SharePoint documents with CRM records. This is why having a combination of Dynamics 365 with SharePoint is popular.
What you need to know - no automatic synchronization of Dynamics / SharePoint permissions
The security models of Dynamics 365 and SharePoint differ significantly. Because of this, there is no automatic synchronization of permissions. This results in documents in SharePoint being accessible to users without the required Dynamics CRM privileges.
This basically means that all SharePoint users can access all documents, including private and sensitive data… even if they don’t have CRM privileges to do so.
If you have a small organization and not that much of sensitive data, you can consider doing this permissions sync manually. In other cases, the best option is to use an add-on such as CB Permission Replicator by Connecting Software. Check our blog about Dynamics 365 and SharePoint security settings.
What you need to know - SharePoint security scope limit
You can store up to 30 million items or files in a SharePoint list or library. But there is a limit on the number of unique permissions you can set of 50,000 items per list or library. This limitation exists in SharePoint 2010 and all following versions. The limit can be lowered but not increased, however, there are things you can do about it… keep on reading!
But first… why is this limit a problem? There are two aspects to consider although this is not that clear if you first look at the SharePoint documentation. Firstly, if you try to go over the 50,000 limit, SharePoint will present the error "You cannot break inheritance for this item because there are too many items with unique permissions in this list".
The second aspect of this problem is the loss of performance. As the number of unique permissions in a list or library increases, you will notice SharePoint performance decreases… even if you are not close to the limit yet. This might happen from around 5,000 unique permissions, although that will depend on your specific SharePoint implementation.
This limit of 50,000 items per list or library is what Microsoft refers as a "Security scope" limit for lists and libraries. You can find this in Microsoft's documentation for
This SharePoint documentation explicitly says: "As the number of unique permissions in a list grows, query performance will degrade. Even though the default limit is 50,000 unique permissions, you might want to consider lowering this limit to 5,000 unique permissions". Microsoft also indicates that "If you try to declare unique permissions after this limit has been reached, you will be blocked from doing so.".
What you can do about it
Now let's talk about possible solutions and workarounds.
The first and most obvious option would be to reduce the number of documents. Unfortunately, this not really an option for most organizations. Documents cannot simply disappear overnight.
The second option would be storing documents elsewhere. The problem with this option is that it either results in a loss of functionality (plus a loss of productivity as you will have to have your users change the way they do things) or in significant extra costs - or both.
The third option is organizing your documents differently. The limit refers to each list or library, so if you have more libraries you are less likely to hit the limit. The problem with this (why is there always a problem?) is that it is hard to do this library organization manually. Moreover, you need your users to cooperate with you if you are doing it manually. Otherwise, you might end up with a library structure no one understands, and no one can keep up…
This can also be done automatically by using
- A document library per period (year, quarter, month, week, day or custom)
- A document library per letter or letter set (based on starting character(s) of the record name or the starting character(s) of the record ID)
- A document library per record
When you have an automatic solution such as the one we just described, you effectively handle both problems that exist with storing CRM documents in SharePoint. SharePoint permissions are correct (based on the permissions defined in Dynamics) and the SharePoint permissions limit is not reached. As an added bonus, the library organization created automatically on the SharePoint side is neat and configured to match a logic that makes sense for your organization. So, if your users try to find the documents in SharePoint, this will be more efficient.
As the problems can be handled gracefully and the advantages of storing the documents in SharePoint are strong, we do recommend using SharePoint to store your CRM documents.
If you want to know more on how CB Permissions Replicator + the add-on SharePoint Structure Creator can help your organization, our experts will be glad to talk to you and walk you through a
By Ana Neto from