Microsoft Dynamics CRM supports out-of-the-box integration with SharePoint, described in detail two previous blogs: SharePoint Integration in Microsoft Dynamics CRM 2011 and CRM 2011 and SharePoint 2010: Configuration and Folder Structure.


One of the features of out-of-the-box integration is that the folders are created as needed—that is, when user navigates to Documents area of the record for the first time.

This is a usually a good approach, but this method can have shortcomings in some more complex requirements, such as:

  • External application relies on existence of the folders.
  • External (to CRM) users also contribute to SharePoint—if the folder for the record does not exist, users may create it with wrong name.
  • Custom naming of the folders is required.
  • Custom SharePoint security is desired.

Out-of-the-box integration will create a folder using the configured structure, using the name of the record:

Microsoft Dynamics CRM-Driven SharePoint Security

In SharePoint, the security is inherited from parent folder:

Microsoft Dynamics CRM-Driven SharePoint Security

Microsoft Dynamics CRM has robust security architecture, with business units, teams, roles and sharing. In the out-of-the-box SharePoint integration, users that cannot view a record in CRM would be able to view the documents directly in SharePoint.

You could maintain the security manually in SharePoint, but this can become cumbersome with large number of records. Also, SharePoint is often considered as an invisible add-on where users only use the CRM interface. Ideally, you want to programmatically mirror the CRM security in SharePoint.

Our approach to solving this is to use Dynamics CRM plug-ins and create SharePoint folders programmatically, break the inheritance, and add permissions where needed.

Here’s the basic functionality of the plug-in:

  • It’s set to trigger at the creation of a record.
  • It will read CRM’s configuration of the SharePoint sites, and will use the configured site without having to configure the site into plug-in registration. This makes the plug-in easily transportable between environments.
  • It will use the SharePoint DWS web service to create the necessary SharePoint folders. You can name the folder whatever you want—it isn’t limited to the record name.
  • It will create the corresponding document location records in CRM. You can title the document location whatever you want—it doesn’t need to be the default ‘Documents on abc.’

At this point, all you’ve done is duplicate the out-of-the-box integration and force it to run at the creation of the CRM record.

The big challenge now is that the required functionalities, BreakRoleInheritance and RoleAssignments, are not available through SharePoint 2010 web services. You’ll have to use SharePoint Client Object Model, which requires that the code must reference to Microsoft.Sharepoint.Client.dll and Microsoft.Sharepoint.Client.Runtime.dll. This means the assemblies must be deployed to the CRM server GAC and the plug-in cannot be isolated. Therefore, this approach is not applicable for CRM Online. For CRM Online, you may use similar code, but create your own web service that the isolated plug-in can call.

Here’s a step-by-step approach to breaking inheritance and adding access to a specific SharePoint group:

1. Set Client Context and find the List:

ClientContext clientContext = new

clientContext.Credentials = new
NetworkCredential(_connectionInfo[“Username”], _connectionInfo[“Password”], “”);

List oList = clientContext.Web.Lists.GetByTitle(listname);

2. Use CAML Query to find specific folder using URL:

CamlQuery query = new

query.ViewXml = “<View Scope=’RecursiveAll’><Query><Where><Contains><FieldRef Name=’FileRef’/><Value Type=’Lookup’>”+FolderURL+“</Value></Contains></Where></Query></View>”;

ListItemCollection collListItem = oList.GetItems(query);



3. If ListItem found, we can break the inheritance:


4. If you want to add certain access to a group, we can do that against ListItem as well. Here is how to add the Contributer role to a group:

RoleDefinitionBindingCollection collRoleDefinitionBinding = new

RoleDefinition oRoleDefinition = web.RoleDefinitions.GetByType(RoleType.Contributor);


oListItem.RoleAssignments.Add(siteGroup, collRoleDefinitionBinding);


With this plug-in, as soon as record is created, the folders are created and security is set:

Dynamics CRM-Driven SharePoint Security

Note that all the items including the subfolders underneath this folder will inherit the permissions from this folder, so you generally only have to do this at one point of each branch.

Microsoft Dynamics CRM-Driven SharePoint Security

Extending from these basic building blocks, you can build a robust, CRM-driven security architecture in SharePoint.

If you want more information regarding CRM and SharePoint Integration, make sure to check also our other blogs:

Happy CRM’ing!

Avatar for Joe D365

Joe D365

Joe D365 is a Microsoft Dynamics 365 superhero who runs on pure Dynamics adrenaline. As the face of PowerObjects, Joe D365’s mission is to reveal innovative ways to use Dynamics 365 and bring the application to more businesses and organizations around the world.