Microsoft Dynamics 365 Blog

Last month I posted on how to create a SharePoint document library using a CRM callout. Using a document library per entity is fine if you aren’t creating a large number of entities, and the documents in the libraries are not related. However, in the CRM world it is very likely that you will have multiple opportunities per account or multiple cases for one account.

Based on this scenario there are a couple different ways that you could structure the document libraries. First is to have a document library per account and create a folder for each new opportunity or case. The second structure would be a single document library with a folder for each account and sub folders for each opportunity or case.  Both of these solutions reduce the overhead of creating lots of document libraries.

However, be aware of the recommended limits for SharePoint document libraries. The recommendation is less than a 1000 document libraries per site. For many businesses this would be exceeded very quickly. In addition, it is recommended to keep any document library view under 1000 (WSS v2) or 2000 (WSS v3) items and the maximum number or documents per library under 2 million. One last limitation that needs to be mentioned is the URL length which is related to folder depth and filename length. The maximum URL length is 260 characters.


Well based on all of this information how would I structure a SharePoint site for a company that has significant repeat interactions with around 50 accounts? Since the business has only a few accounts with frequent interaction I would create a document library per account and use subfolders for each opportunity.

For simplicity you can use the account name as the name for the document library. However, be aware that very long names or duplicate names will cause problems. If this is a significant problem then you can use a truncated name attribute and the ID guid. This won’t be very user friendly but will generate a more predicable library name. The same issues exist for opportunities. At this point I would suggest truncating the Opportunity name (subject) to ~50 characters and appending the opportunityID when creating the folder, because I see many repeated opportunities titles.

So now we have an idea of how to the library structure will be we need to handle a couple of key tasks to make this work.

For creating the account document library use the code from my previous post.

For creating a folder in a document library use the UpdateListItems method of the lists web service. This method takes two parameters the list name, and an Xml string called a batch. This Xml string can contain a set of method elements which describe the type of updates to execute.

API Reference:

Here is a sample batch string for a folder:

<Batch OnError=”Return” RootFolder=””>

      <Method ID=”1″ Cmd=”New”>

            <Field Name=”ID”>



            <Field Name=”FSObjType”>



            <Field Name=”BaseName”>





In the sample above there are two key fields. FSObjType is and system column that document libraries have which determines if the item is a folder (1) or document. BaseName is the file name or folder name in this case.

The code snippet below builds a batch Xml string and sends the batch to the SharePoint server creating the folder in the document library specified by the listname parameter.

public static System.Xml.XmlNode CreateFolder(string listName, string folderName)


    System.IO.StringWriter sw = new System.IO.StringWriter();

    System.Xml.XmlTextWriter xw = new System.Xml.XmlTextWriter(sw);



    // build batch node


    xw.WriteAttributeString(“OnError”, “Return”);

    xw.WriteAttributeString(“RootFolder”, “”);


    // Build method node


    // Set transaction ID

    xw.WriteAttributeString(“ID”, Guid.NewGuid().ToString(“n”));

    xw.WriteAttributeString(“Cmd”, “New”);


    // Build field ID


    xw.WriteAttributeString(“Name”, “ID”);


    xw.WriteEndElement(); // Field end


    // Build FSObjType


    xw.WriteAttributeString(“Name”, “FSObjType”);

    xw.WriteString(“1”);  // 1= folder

    xw.WriteEndElement(); // Field end


    // Build Base Name field from folder


    xw.WriteAttributeString(“Name”, “BaseName”);


    xw.WriteEndElement(); // Field end


    // Close Method & Batch elements

    xw.WriteEndElement(); // Method end

    xw.WriteEndElement(); // Batch end




    System.Xml.XmlDocument batchElement = new System.Xml.XmlDocument();



    //Setup web service

    DocLibraryCallouts.SharePointLists.Lists listService = new DocLibraryCallouts.SharePointLists.Lists();


    listService.Credentials = new System.Net.NetworkCredential(“someuser”, “somepassword”, “somedomain”);   


    // send update request to sharepoint to create the document folder

    System.Xml.XmlNode result = listService.UpdateListItems(listName, batchElement);

    return result;


These last two post should provide the basics working with document libraries using CRM callouts. I hope this helps you integate Microsoft CRM and the SharePoint products. If you have any other ideas for integration between Microsoft CRM and SharePoint leave suggestions in the comments section.

Hope this helps,
Rich Dickinson

We're always looking for feedback and would like to hear from you. Please head to the Dynamics 365 Community to start a discussion, ask questions, and tell us what you think!