In today's fast-paced business landscape, staying ahead of the competition requires efficient and effective solutions. According to Microsoft’s Work Trend Index, nearly 70% of employee report that they don’t have sufficient time in the day to focus on “work”, with more time being spent Communicating than Creating.
Microsoft 365 Copilot is designed, with Microsoft’s cloud trust platform at its core, to allow for employees to both be more productive, reduce the time spent searching for information, performing mundane tasks, and other low-value activities.
CRM & SharePoint Integration
If you are familiar with the very powerful interface which allows a CRM (Customer Relationship Management) user to attach seamlessly documents to a given entity (account, contact, opportunity, etc.) using the CRM/SharePoint integration, you may also be aware of a potentially dangerous gap in the security model.
I have found that the out-of-box integration is well designed, intuitive, and easy to use. I can take any document and with a few clicks of the mouse, associate it to a CRM entity while saving it in a SharePoint library. This interface gives users the best of both worlds: CRM for field level data and SharePoint for document management. The possibilities are seemingly endless.
A few examples include storage of Statements of Work tied to an opportunity, MSAs (Master Service Agreements) attached to an account, design documentation related to an opportunity, and in the case of an "XRM" application - anything goes. Perhaps it is an XRM ("anything" Relationship Management) solution for tracking patients for a healthcare process - patient records can be attached directly to their corresponding contact record in CRM.
With all the endless possibilities available to manage data and documents, one of the first considerations (beyond the task itself) is the security. There are an infinite number of reasons and methods for securing data and documentation depending on the particular business case. There are as many ways to secure this data as organizations are using the products. In a CRM Sales Automation implementation, many organizations like to keep a separation between groups of salespeople, business units, or departments. For obvious legal and ethical reasons, the healthcare industry must be vigilant in securing sensitive documents. I could go on and on, but I'll spare you from belaboring an obvious point.
Security is critical.
So this is all fairly obvious, but if you are new to the out-of-the-box CRM/SharePoint integration, you may not realize the complex problem this presents. Both CRM and SharePoint have robust models for securing their respective data/documents. Most security requirements can be handled adequately in either application, respectively. However, there is a gap: The CRM security model is completely separate from the SharePoint, security model. Period. In other words, SharePoint does not know or care what level of access a CRM user has to a particular CRM entity. Once the documents are uploaded to SharePoint, it is up to the SharePoint administrators to maintain who has access to those documents.
At the very least, this introduces a maintenance burden to the CRM SharePoint administrators by introducing two different security models to be administered and kept in synch. At worst, it exposes the organization to serious problems if the wrong people gain access to the wrong documents.
As with any data integration project, the first consideration is whether the information needs to flow in both directions. In other words, can we simplify by making one system the "source of truth", thus significantly reducing the complexity involved in a bi-directional integration? We decided that since the context of the action (attaching a document to an entity) is, in this case, originating in CRM, that it makes the most sense to identify the CRM Security as the "source of truth". In other words, SharePoint security should always match CRM's security, and if it changes in SharePoint, it will not affect the CRM security. This first step took us down the path to closing the gap.
As most people are aware, CRM and SharePoint both possess very robust API's (Application Programming Interfaces). For the non-programmers, this means we programmers can interact with an application in a safe, controlled way without having access to the core code or database. By combining elements of both the CRM and SharePoint API's, we were able to achieve some degree of security synchronization between the two systems. In a nutshell, a CRM user's access to an entity (read, write, delete, etc.) will translate directly to that same user's SharePoint access to any documents associated with that entity.
Access to an entity in CRM can come about through many different events. Ownership, access teams, business unit, management hierarchy, roles assigned, etc. For any given entity, changes to any of these elements can affect a user's ability to read, update, or delete an entity. And the access level is not readily visible to the naked eye.
To solve this complexity, we used an event-based model, which determines when something changes, and based on what is (not what was) regarding access levels, sets the equivalent access level in SharePoint. For example, if a user is shared to an account in CRM, and given explicit "read only" access to that account, then this should have no effect on any other user or any other account. The corresponding security update in SharePoint is simple - give that user "read only" access to any documents associated with that account. However, if a role's access changes, this has the potential to affect many, many entities and many, many users. If a widely shared security role gives read/write access to accounts at the organization level, and this role is changed so that it now only gives read access at the user/ownership level, then every user with that role needs to be checked against every entity in CRM. In this case, a lot of processing is involved to sync up the SharePoint documents.
To avoid problems with the user experience, we opted to handle these security updates asynchronously. In other words, the triggering event happens, and the SharePoint update process occurs in the background. The CRM user does not have to wait for the SharePoint security process to complete. So the CRM user can continue with his/her activity uninterrupted. Naturally this means the security update is "near real-time". Depending on current system load, network speed, etc. there will be some (usually small) amount of time when the CRM entity user access does not match with SharePoint. This is much faster, however than having a human being try to keep the two in synch manually. One could theorize that in a system with more than a few users and entities, it rapidly becomes impossible to be accurate, much less timely.
Another consideration with asynchronous processing is handling failures. Even a perfectly written codeset can fail under certain environmental circumstances. If the network goes down, SharePoint services are not available, network security levels changed, etc. it is possible that the process can fail after the CRM update is made, but before the corresponding update can be made in SharePoint. We handle this in a straight forward (simple) way. We run a batch process at night which syncs up all SharePoint documents with their corresponding CRM entities.
The CRM / SharePoint integration is wonderful, and I believe that the gap in the security should not stop anyone from taking advantage of this amazing tool.
Align your whole company with a focus
Learn more in our free ebook!
It's About Data, Not Assumptions
[How to win customers & increase profits]
