Just read a very interesting post by Wictor Wilén, a SharePoint MVP here in Sweden. He strongly argues that Yammer is planned for termination by Microsoft and lists several, very good reasons for this. Do read it.
|Is Yammer breaking up?
Why is this important for us working with Dynamics CRM? As you might know there is a built-in integration between Dynamics CRM and Yammer, where Yammer can be used to replace the Activity Feeds. This gives the organization using the Dynamics CRM system increased use of the feed functionality, as most of the features of Yammer Enterprise can be used directly from within CRM. It will create a thread for each record. For more information on how to set it up and how it works, read this Tech Net article: https://technet.microsoft.com/library/dn850385.aspx.
Recently, in CRM 2015 Spring Update (version 7.1) it is also possible to integrate CRM to Office Groups. If you read Wictor’s Post, you will note his referal to how this most likely is the informal successor to Yammer internally within Microsoft. The Office Groups integration makes the collaboration Picture in Dynamics CRM even more complicated as there now are Three different ways of collaborating;
– Activity Feeds
– Office Groups
However, if Yammer really is to be deprecated, then this Picture clears a bit.
Another interesting fact is that there has been nothing done to the Yammer integration in CRM for several versions. It was released for CRM 2013 and it still has a lot of basic features missing, like if it is enabled for an organization, it cannot be removed. (https://msdn.microsoft.com/en-us/library/jj945277(v=crm.6).aspx)
If Yammer was to be officially terminated, do note that Wictor (and I in this post) are just speculating, migrating the existing data from Yammer to ActivityFeeds or OfficeGroups is also a non-trivial issue. As Wictor mentions briefly in his post, the Yammer API:s have some areas which can be improved.
So, based on this. I would not advice any current CRM system owners to enable the Yammer integration unless Microsoft starts investing in Yammer and/or the CRM-Yammer integration.
I would also be more than happy to have a discussion on this subject in the comments section below.
MVP, Founder and CTO at CRM-konsulterna AB
As many of you know Microsoft Dynamics CRM 2011 has a built in integration with SharePoint. As a former SharePoint consultant I have reviewed it to see how it looks, not only from a CRM perspective but also from a SharePoint perspective and there are some major issues from this perspective that one needs to take into consideration. For those of you who attended my presentaton at SharePoint Exchange Forum 2012 22-23 of october this year this is more or less what I presented.
First of all, to make it work properly, you are recommended to install a special addon to SharePoint called the CRM List Webpart. This makes the document lists in SharePoint get a more CRM-y look. I found a very good blog with detailed instructions on how to install it which, at least for me, worked perfectly; http://mossdevsharepoint.blogspot.se/2011/07/integrating-crm-2011-with-sharepoint.html
When this is done, you simply go into Settings-Document Management and click on the “Settings for Document Management”-button. This will start a wizard that will let you configure the integration.
It will default which entities are to be used for the integration and you are also asked for the base site URL. This site will contain all CRM documents unless you do some manual configuring (as described below) so I generally recommend that you create an empty site. It will also create one document library per entity that you have selected in this site.
The result will look something like the following:
|Document libraries created in SharePoint (left) will match the entities selected in the document management settings in CRM (right)
For now, let’s refrain from the ranting and just note that this is how it will look.
If further entities requrie document management, these can be added later by re-running the wizard.
After you have selected which entities you would like to use document management for, the wizad will show you the following query:
|Folder Structure selection
This query is very important to the structure of documents in SharePoint. If you chose to use a folder structure based on an account or contact (my recommendation is generally to use Account here if this is your primary customer entity and only use contact for strict B2C).
If you choose the structure based on account, a folder structure will be created in the SharePoint Document Library as follows:
|Folder structure if based on account for an account with sub-opportunities and quotes
Do note the folders called Opportunity and Quote that have been created. Rant below.
If, instead the structure is selected that is not based on an entity, a flatter structure will be created.
|Folder structure created if not based on an entity
The folder structure is a lot flatter, but note the difficulty of trying to identify the quote folders for the opportunity “CRM Online for A Store”. As no hierarchy is used, the only way of distinguisishing sub-objects is to use descriptive names as I have done with the opportunities in this case to indicated that all your bases are belong to us.
To be total just, no object specific document folders are actually created in this step. This is something that is done the first time you open the documents tab for the object (ex. the account “A Store”).
So to give a quick review, the following can be concluded:
– Hierarchical structure is to be selected if documents are to be navigated to with SharePoint as the flat structure makes it very hard to understand which folder belongs to which place.
– When you reparent something in CRM, for instance if the opportunity was created towards the wrong company in a corporate hierachy and you reparent the opportunity. This will not trigger any changes in SharePoint which is ok if the flat structure is used but not so good if the hierarchical structure is used as the opportunity documents will be stored under the wrong account.
– The flat structure gives a clearer division of document types. For instance all Quote documents will be stored in a separate document library and all documents related directly to accounts in another.
– With the hierarchical structure, most documents will be stored in the account document library which for larger installations would incurr large amounts of documents. This will make it more diffucult to use.
You can also connect your CRM objects manually to a specific folder/document library, this enables you to create a more logical structure in SharePoin, like one site per customer, and then manually connect each of these site’s document libraries to the corresponding account in CRM. The problem with this is that you have to follow the following steps to do it (example for a customer setup)
- Create the account in CRM
- Create the customer site in SharePoint
- Copy the right part of the URL from the document library in SharePoint.
- Add a new document connecion in CRM and past the document library from (3) into the field.
This will not work in normal CRM implementations as the tasks are too complicated for normal users, and especially salespeople to do.
Another perspective that is important to remember that the security (privilages) for the document libraries are not replicated from CRM to SharePoint. SharePoint has a more traditional top-to-bottom security architecture and the security architecture of CRM is a lot more complicated and it is very complicated to try to replicate the privilages for a specific object in CRM to the corresponding folder in SharePoint. This is due to the fact that the CRM security architeture is dependent on both owner (user or team) and sharing that have been made. For instance adding or removing a person from a team would requrie you to check all ownerships and sharings for that team in order to mimic the security settings. The recommended way of handling this is to allow all people in a group to have access to all documents in SharePoint and then remove access (inheritance) for the folders that require special permissions. It requires special handling and would be very cumbersome for large organizations.
My final conclusions are hence that the use of SharePoint as a document storage tool for CRM greatly enhances the document management funtionality of Dynamics CRM but it has not been designed to enable logical use of the documents from a SharePoint perspective. The security aspect is also somethnig that will reduce the way it can be used. I would also recommend that the documents are to be accessed mainly from CRM and only in very special cases from SharePoint.
I am not aware of any third party addon that increases this functionality, if you do, please leave a comment!
MVP, CEO and owner at CRM-konsulterna AB
The NDA of the new version of SharePoint 2010 has been lifted and hence a lot of new functionality is out!
You can read a lot about it on the SharePoint Team Blog here: http://blogs.msdn.com/sharepoint/archive/2009/10/19/sharepoint-2010.aspx
From a CRM perspective, this is very interesting. The new version of CRM is rumored to have a much tighter integration with SharePoint, so from that perspective it is almost essential to learn a bit more about SharePoint.
There are some areas of SharePoint that are of special interest from a CRM perspective:
- Enhance BI functionality including performance Point server now included in the new SharePoint
- Business Data Catalog enhanced – an excellent tool to work with in relations to CRM
- Enhanced Document Management – one of the weaker parts of Dynamics CRM 4 is the built in document management so integration with SharePoint in regards to document management is often used.
- Enhanced API and development capabilities. When integration with SharePoint development is often required to create the necessary functionality. The SharePoint API is currently ok but compared to the excellent API of Dynamics CRM, it can do with an upgrade. Hopefully to the mark set by Dynamics CRM.
So that is all good news.
However, there is still one major issue from a CRM – SharePoint integration perspective that Microsoft REALLY need to address and that is the licensing issues of SharePoint users working in a very slight way with CRM data by, for instance, looking at data from a data warehouse in SharePoint with drill-down functionality. Today, all users with access to this need to have a full read only CRM license. Similarly, if there is a webpart used in SharePoint to create leads in CRM, but with no other need for access, a full CRM CAL is required for all users of the Intranet since they are employees and hence cannot use the external connector license. This is preposterous! Please Microsoft, we really like CRM, and we want to pay our dues, just make it fair!
Microsoft Dynamics CRM Chief Architect
Today I ran into some problems concerning People-search in MOSS 2007. My customer was using https for their main sharepoint site and I had installed the mysite host on the same web application (in https://servername/mysite) according to the specifications found around the net.
Well, my customer just couldn’t get the people search to work, and I had heard that there were some problems with using it on a site that runs on https (http with ssl), so I wasn’t very surprised. As a bit of backgroud, the peoplesearch is set up as a contentsource in the search using sps3://servername. The server in this case should be the web application hosting mysite.
Well, how to solve it. First of all I tried to just create and extension of the sharepoint application on http port 2000 (http://servername:2000). It worked just as it should, when I browsed it, it worked and I was also tranfered to the default site (https://servername).
I tried adding this as a content source instead of the old one, in other words:
sps3://servername:2000, sadly it didn’t work.
As a matter of fact, we had got it to work previously in the same environment. We had first installed sharepoint on http://home and then added https://home.company.com with an extension and an alternate access mapping. The later was used as the address to be used from the outside, by using MS ISA as a reverse proxy. After a while, the customer complained about problems with people copying/emailing url:s that didn’t work from the outside. (the url was http://home/… and not https://home.company.com/…, so not very strange. This resulted in the action of removing the alternate access mapping of http://home (the original one) so that only https://home.company.com remained (and was hence set at the default). This worked great, people could enter “home” in their IE and they would reach the site https://home.company.com.
However, when I removed the alternate access mapping for http://home, people search started failing.
So, the remedy, I added an alternate access mapping for http://home:2000 in the zone Intranet (doesn’t really matter, which zone as long as it isn’t the default), re-indexed the search server and made a full crawl that worked like a charm! The point of using TCP port 2000 was that is is very unlikely that a user might just happen to enter that, it could just have been 1234 aswell…
CRM and SharePoint Consultant
In the posting before that, he also describes how to create your own custom edit form for a document properties page. This is very useful in these cases, so please have a look at that as well. (http://sebastiant.blog.com//custom+forms/).
CRM and SharePoint Consultant