2nd March 2017 at 2:57 pm #367
I’d be grateful for some gotchas about what happens when you enable SharePoint online storage for a large existing online CRM instance?
I can connect CRM to SharePoint in a dev environment super simple but cannot find any good advice about how it handles or doesn’t handle 200GB+ worth of records with documents and emails attached as notes.
Also, it appears you cannot switch from Account/Contact centric structured folders to Entity centric ones once you’ve gone chosen one over the other. Is that correct?
- This topic was modified 10 months, 3 weeks ago by Darrel.
2nd March 2017 at 4:06 pm #376
Darrel – there a few things to consider and plan for, especially if you have a large number of CRM records (or will have over time). I am working with a client who has 5.5 million documents in SP associated to CRM records (largest single library is 2.4m) so my thoughts on list view threshold are from bitter experience!
Quick brain dump:
Assuming your using server-side integration (as the old list component uses a code sandbox solution that you won’t get working online anymore!):
-be aware the permissions on your CRM records do not flow to the document libraries in SPO, this will also mean a user without deletion rights in SP will still see the Delete button in the document grid in CRM 🙁
-make sure you enable indexing on your columns to help with the list view threshold (but to a certain extent you’ll get screwed over by this sooner or later!)
-custom content types and columns won’t show up in the document grid (only OOTB ones)
-As far as i am aware, turning on SSI won’t move your associated documents into SP automagically
-I would advise using the DocCenter template rather than TeamSite for the SP site
-i suggest scripting the creation of the SP DocLibs, set the URL to the entity internal name (else it wont work!), the library display Name is up to you but follow a decent convention!
-a deletion invoked from the grid in CRM calls the SP API and does a hard delete, document does not go to the recycle bin 🙁
2nd March 2017 at 5:23 pm #380
I agree with all of Matt’s points. Basically if you are doing this with any sort of scale you need to move away from the out of the Box approach and develop something yourself. SharePoint Site and Document Locations are the entities you want to be looking at in CRM.
However as you are Online I would seriously look at the Office 365 Groups integration to CRM. Far better integration, and much more scalable. You may still need development on top, but it will get you part of the way there.
3rd March 2017 at 8:49 am #385
You mention Notes and email attachments. As far as I am aware these do not get sent over to SharePoint as part of the integration.
Last year I developed a tool for a customer who had 1.5million documents in email attachments and Notes. We build a tool that stripped these documents out of the email / note, sent them over to SharePoint and then replaced the attachments view in CRM with a new one that simply provided a link to the SharePoint Document. SO it looked like the attachments grid.
This saved the customer a LOT of money as SharePoint Online Storage is phenomenally cheaper than CRM online storage.
There are a few gotchas though.. if you forward the email from it wont include the attachment (as it technically doesn’t exist any more) and if you change the document in SharePoint it will no longer be a true reflection of the document as it came in on the email. Also, if you delete the file in SharePoint then it will be a broken link in CRM (unless we code those changes back in, which we didn’t for that client). We did use Document ID links in CRM so that if a file is moved or renamed in SharePoint the link will carry on working.
I did consider productising this and charging a small fee per document transferred, but I realised I would need to be migrating hundreds of thousands if not millions of documents a month to get any sort of real return!
However, we could always re-purpose this tool if you were interested?
3rd March 2017 at 9:46 am #386
Many thanks for the helpful pointers.
I didn’t think OOTB would cut it but was foolishly hoping connecting one to the other would kick off some massive crawl and purge of CRM documents and pump them into SharePoint linked to the record. Now looks like our interest in saving money on CRM storage is actually a migration project.
What I cannot find written anywhere is – once you pick one folder structure over the other you cannot swap, is that correct? I.e structure by account and contact vs Entity. I can find articles saying you have to decide upfront but nothing about how detrimental it is if you need to swap.
@mark – good to know. Early days for us
3rd March 2017 at 10:11 am #392
Darrel – while I don’t think there is anything preventing you from switching from Entity centric to/from Account/Content centric, but the fixing up of the references/associations will be something you’ll need to solve yourself (I dread to think to pain of doing this!), so the guidance to decide up front is sound, IMO.
Without knowing the business you’re working with it’s impossible to advise on specifics, but I would say as a rough vanilla rule: for smaller/simpler B2C/B2B CRM the Contact/Account model is great, for medium B2B the Account centric approach may work too, for anything else use the Entity model. it may be an extra click for the users to get through the associated records and into to docs associated, but it offers more flexibility and scalability, especially if you have a load of custom entities within your CRM.
4th March 2017 at 3:24 pm #410
Another gotcha that I have come across is the lack of transfer of the CRM security model into SharePoint. While this may be unnoticed if CRM is the primary tool and SharePoint has not direct links to the CRM content, Search can expose all of the content that is associated with CRM.
If the content from CRM is not exposed or interacted with directly via SharePoint, I would recommend setting the sites to not be indexed in Search.
7th March 2017 at 2:05 pm #430
What are your thoughts on GUID removal from folder names using something like https://orgdborgsettings.codeplex.com/ ? It looks nice and tidy until you have two common case names and it files all items to a single folder when in fact it’s only the case name that’s common and the content relates to different contacts or accounts.
7th March 2017 at 11:35 pm #432
Why would you want to remove the GUID from the folder?
Most users will access the content stored in SP via the CRM UI so will be blissfully unaware of the non-human friendly naming. I see no benefit in doing this. Only pain.
8th March 2017 at 1:30 pm #438
Pain is good. Or rather knowing pain is ahead is good.
I saw a few discussions about removing it and I wasn’t sure what purpose that served. Was it because it looks nicer or was it because URL length was being exceeded by nested folders and long entity and document names?
I’ve uploaded a visual by way of example
26th September 2017 at 9:05 pm #700
For document migration you can try and use the Kingswaysoft connectors for CRM and SharePoint. (http://www.kingswaysoft.com)
You need to know your way around SSIS to use these but they are by far the cheapest and easiest to use.
If you create a sharepoint site which your CRM instance can upload documents to, every user will have access to every document regardless of whether they have rights in CRM to see the record that the documents are linked to.
The lack of shared security is a huge issue. You can’t fully duplicate the security model but I provide some suggestions to tighten the security in my Pluralsight course
You can watch it for free if you take the 3 month free pluralsight trial on the Visual Studio website
All the best
Dynamics CRM Solution Architect
You must be logged in to reply to this topic.