PowerObjects Blog 

for Microsoft Business Applications


CRM 2013 and SharePoint Integration New Feature


CRM 2013 and SharePoint Integration New Feature

The Microsoft Dynamics CRM 2013 and Microsoft SharePoint 2010/2013 integration remains much as it was in CRM 2011 and is designated as not being a refreshed entity. However, there is a nice improvement in the document location and folder name.

The setup is exactly the same in CRM 2013 as it was in CRM 2011, which you can reference here.

Here is a summary of the setup for a new CRM 2013 deployment:

  1. Download the CRM List Component SharePoint solution and upload the appropriate version (SharePoint 2010 or 2013) in the SharePoint solution gallery.
  2. After successfully uploading and activating the CRM list component in SharePoint, navigate to Settings > Document Management in your CRM 2013 organization.Dynamics CRM 2013 and SharePoint
  3. Follow the same steps for 2013 as completed in CRM 2011 to enable the CRM 2013-SharePoint integration. Your new valid SharePoint site should be listed under your active SharePoint sites.Microsoft Dynamics CRM 2013 and SharePoint Integration
  4. Navigate to a CRM account record and locate Documents in the command bar. You'll be prompted that the folder will be created.


Now for the cool new part. The folder name is no longer simply the account record name—the CRM record's GUID is appended to the folder! You can see that the CRM document location record displays the folder name.

Navigate to SharePoint and see the corresponding folder.

This improvement in the CRM 2013 and SharePoint integration simplifies additional development. It should also should expedite further integration between the two applications, because now SharePoint knows the unique ID of the CRM record!

For other CRM 2013 information, see our full list of CRM 2013 events and educational offerings.

Happy CRM'ing!

Joe CRM
By 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.

26 comments on “CRM 2013 and SharePoint Integration New Feature”

  1. Is this post a joke?

    I raised this "cool new feature" to Microsoft and reported it as a bug. I don't understand what benefits my users would get from seeing the record GUID in all created folders when navigating from Sharepoint?

    1. Is it possible to deactivate this feature or stop CRM from appending GUID as default to all entity folders?

        1. So there is no easy way to de-activate it, but one alternative is to instead of using the out of the box integration to create folders in sharepoint via a plugin and set the folder location in crm via thsi plugin too. This would give you total control of the folder naming in sharepoint. This is how we used to do sharepoint integration back in the crm 4.0 days when out of the box sharepoint integration was not available.

  2. Hi Peter.

    This is actually a very cool feature (not a bug).

    Let me explain. By appending the GUID as default on the entity folder, it should be really easy to create a service on the SharePoint server (based on FileSystemWatcher) that crawls (preferably async) the metadata from the CRM entity (WSDL) and updates the SharePoint system. This way we will still are able to use CRM as we are used to (I agree that it might be distracting to see the GUID appended to the entity name) and still be able to ensure that metadata from the CRM system is persisted to SharePoint (Low coupling and even higher cohesion between the two system, loving it !!!)

    Lets say that unitl this "cool new feature" we've had a few challenges in this area 😉

  3. This new "feature" doesn't make that much sense to me either. The odd part is that SharePoint supports metadata on folders and even has specialized folders called Document Sets that are arguably even better suited for this type of metadata attachment. While it is really nice to have the guid there are better options.

    1. Yep - we hope that in the near future there will be a new web part that takes advantage of metadata instead of relying on the folder names.

      1. Hi Folks - Just an update that we can now turn this off and go back to the old style. YOu need to use the db org settings tool - https://orgdborgsettings.codeplex.com/ Then look for a setting called 'CreateSPFoldersUsingNamesAndGUIDS' and set to 0. THis setting is not listed in the documentation but does appear in crm online orgs.

  4. Without the GUID, how did previous integration deal will folders for organizations with same name?In our business, our market is local churches, so organizations with same name is very common for us. I am not an expert, but off the cuff, adding the GUID seems to be appropriate improvement for the out of the box SharePoint/CRM integration.

    1. Correct - in crm 2011 if two accounts had the same name they both looked at the same folder. This was an issue to many of our clients that have accounts with the exact same name.

  5. It is too bad they could not figure out how to pass the GUID to SharePoint as folder metadata rather than by appending to the Folder Name. Agree that Users don't want to see GUIDs. That being said, it is cool that it simplifies automation.

  6. OK This is just stupid insanity. Sure it makes programming easier, I get that. However it makes the solution UNUSABLE!! Our entities are hierarchical to 3 or 4 levels and when browsing SharePoint folders directly looking for files, the folder name breadcrumbs are so long you can not find ANYTHING. Our sales force has become so frustrated they have abandoned the CRM interface and are just uploading and creating folders all willy-nilly. We are now looking to give up the entire solution because no one can find anything anymore. This was the worst idea ever.

  7. "However, there is a nice improvement in the document location and folder name."

    A nice improvement? Our Office 365 CRM was upgraded to 2013 over Christmas and I've had nothing but headaches since we've all returned to work after the holidays. We have thousands of accounts on CRM with documents stored in SharePoint, and this "nice improvement" means that we're having to go through all of the accounts one by one to correct the location on SharePoint (i.e. removing the GUID).

    This "feature" should be optional not the mandatory default.

    I've been in contact with Microsoft Support about this, they're in talks with the developers to look into a solution.

    Has anyone else encountered the same problem?

  8. I understand that CRM developers (<1% of the enterprise) MIGHT want the GUID in the name (in fact I think most will be horrified!) but no one else will want this - specifically preSales. I can only imagine trying to convince potential customers that this naming 'convention' is a positive!
    Both of these products are owned/developed by Microsoft - I find it inconceivable that they cannot
    a) allow customisation of the folder naming (e.g. allow the entity folder to be called something under than the CRM entity and the record to be a customisable value such as shortname rather than title
    b) create a GUID column on the Document library in SharePoint to link back to the creating entity (for the developers they are supposedly catering for)
    c) allow attributes from the CRM entity be passed through to SharePoint columns
    Microsoft insist that best practice in SharePoint is to use Metadata for Navigation. Yet integration from one of their flagship products, CRM, only handles folders!

  9. I fully commit to you ! Another nice new feature is, that the long foldername produces errors in the syncronisation with skydrive pro !

  10. Hi Joe, this is a nice post. However MS never seems to bother to actually develop with someone who has to use it next to them.
    @Daniel: I agree, I also had nothing but headaches with MS so called improvements; I spend more time fixing things than ever before. Would be nice to seem some development with the user in mind; not the developer; quite frankly I am looking for alternative options since MS products other than Office have become unusable in a production environment.
    @Microsoft: Next time you develop something have someone use it (a real world user) before you try to sell it.
    @gentauro:disqus : "it should really be easy to create", mate this is the exact problem; first it is not easy; second I am not selling MS products to my clients where they have to fork out another few thousand $ just to get the development finished, which MS should have done in the first place

  11. The GUID is not appended on the parent entity if a document is added to a child entity before the parent folder
    exists. Is this a bug?

    1. Hi Marcus - If the folder already exists it will never be changed. In rm 2013 we can control if crm adds the GUID to the folder name or not. We have seen systems that a nbr of folders were created without teh GUID, then this setting was changed to append guid to folder name. existing folders are not modified only new ones. This setting is CreateSPFoldersUsingNamesAndGUIDS and can be changed via the org db settings tool from codeplex.

      1. I believe he means when you have a child entity and you create a sharepoint location the child entity will have the guid but the parent entity will not have the guid. e.g contact/firstname lastname/loan/loanName_GUID.
        I think it should be contact/firstname lastname_GUID/loan/loanName_GUID. Is there a way to make it so that it does this?

        1. Hi - Unfortunately this is not configurable with the out of teh box sharepoint integration. Only option is to do a custom sharepoint integration were you then have full control of folder names, locations, etc......like the good ol crm 4.0 days when we had no out of the box sharepoint integration.

  12. Thanks for the post Joe! I would just add that whenever integrating Dynamics CRM and SharePoint, there are certain security risks. SharePoint doesn't replicate the users access rights from Dynamics CRM. Therefore, unauthorized users can access Dynamics CRM documents stored in SharePoint. The only out- of- the box product to deal with the issue is CB Dynamics CRM - SharePoint Permissions Replicator. The solution copies the entire data model from Dynamics CRM to SharePoint. Learn more at: http://www.connecting-software.com/dynamics-crm-sharepoint-permissions-replicator/ cheers

  13. Thanks for the post Joe! I would just add that whenever integrating Dynamics CRM and SharePoint, there are certain security risks. SharePoint doesn't replicate the users access rights from Dynamics CRM. Therefore, unauthorized users can access Dynamics CRM documents stored in SharePoint. The only out- of- the box product to deal with the issue is CB Dynamics CRM - SharePoint Permissions Replicator. The solution copies the entire data model from Dynamics CRM to SharePoint. Learn more at: http://www.connecting-software.com/dynamics-crm-sharepoint-permissions-replicator/ cheers

  14. Thanks for the post Joe! I would just add that whenever integrating Dynamics CRM and SharePoint, there are certain security risks. SharePoint doesn't replicate the users access rights from Dynamics CRM. Therefore, unauthorized users can access Dynamics CRM documents stored in SharePoint. The only out- of- the box product to deal with the issue is CB Dynamics CRM - SharePoint Permissions Replicator. The solution copies the entire data model from Dynamics CRM to SharePoint. Learn more at: http://www.connecting-software.com/dynamics-crm-sharepoint-permissions-replicator/ cheers

PowerObjects Recommends