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.

development

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!

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.

There are 30 comments on this post

  1. Avatar for Joe D365
    Peter Page
    November 5, 2013

    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?

    • Avatar for Joe D365
      Mrudula
      December 3, 2013

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

      • Avatar for Joe D365
        Mile
        December 5, 2013

        Yes I also want this de-activated

        • Avatar for Joe D365
          alexfagundes
          December 5, 2013

          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. Avatar for Joe D365
    gentauro
    November 5, 2013

    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. Avatar for Joe D365
    SharePoint Guy
    November 10, 2013

    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.

    • Avatar for Joe D365
      alexfagundes
      December 5, 2013

      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.

      • Avatar for Joe D365
        alexfagundes
        April 16, 2014

        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.

        • Avatar for Joe D365
          Mateo Bianco
          October 9, 2015

          Thank you so much! This works for me!

  4. Avatar for Joe D365
    TB
    December 3, 2013

    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.

    • Avatar for Joe D365
      alexfagundes
      December 5, 2013

      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. Avatar for Joe D365
    Joe Newstrom
    December 18, 2013

    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. Avatar for Joe D365
    E2
    December 20, 2013

    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. Avatar for Joe D365
    Daniel Wright
    January 7, 2014

    “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. Avatar for Joe D365
    JohnM
    January 23, 2014

    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. Avatar for Joe D365
    HaraldM
    February 5, 2014

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

  10. Avatar for Joe D365
    Gashaw
    February 12, 2014

    Have you customized the IFRAME buttons? is it possisble to hid “Open sharePoint” ? If yes How?

  11. Avatar for Joe D365
    Melanie
    May 9, 2014

    Hello JoeCRM. Mostly the customers are not satisfied with the standard integration for SharePoint because you could only create SharePoint folders out of Dynamics CRM. What about lists, sites, userdefinied pages and so on. A solution that allows to integrate SharePoint with all it’s features, as well as OneNote WebApp is this one: http://www.protechnology.de/de/Consulting/CRMSharePointIntegrator/EN.aspx
    If you like to test it, let me know.

  12. Avatar for Joe D365
    Alex Goodside
    July 31, 2014

    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

  13. Avatar for Joe D365
    Marcus
    October 28, 2014

    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?

    • Avatar for Joe D365
      Joe CRM
      October 29, 2014

      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.

      • Avatar for Joe D365
        Jacob
        April 22, 2015

        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?

        • Avatar for Joe D365
          Joe CRM
          April 24, 2015

          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.

  14. Avatar for Joe D365
    Jana
    April 25, 2016

    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

  15. Avatar for Joe D365
    Jana
    April 25, 2016

    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

  16. Avatar for Joe D365
    Jana
    April 25, 2016

    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

Leave a reply Required fields are marked *