CRM 2011 UR12 and SharePoint Integration

After having applied the Polaris upgrade (update roll-up 12) the native CRM/SharePoint document integration stopped working. There were two different ways in which this issue manifested itself:

1. When clicking on the Documents link we just received the "spinning wheel" and the page did not load
2. On the occasion that it did succeed to load, the "New" and "Add" buttons did not work i.e. nothing happened at all when clicking those buttons preventing new documents from being added.

As I discovered, it is apparently necessary to update the List Components of SharePoint following the application of UR12. The updated List Components can be downloaded from the following location: 

http://www.microsoft.com/en-us/download/details.aspx?id=5283

This issue is also described in the following KB article along with the steps required for installing the List Component:

http://support.microsoft.com/kb/2810528

Data Import Options

When discussing data imports to CRM there are 2 distinct scenarios:

Data Migration

Data Migration generally refers to a large scale conversion effort and is typically performed as part of a CRM Go Live effort where data is migrated from the legacy system and is usually quite an involved effort. This exercise is technical in nature, typically performed by IT professionals and requires a great attention to detail. Correspondingly the migration logic is also usually quite involved. Meaning that there can be quite a bit of data transformation as part of the migration exercise. And if migrating from another system, you typically want to be able to connect to the data in the legacy database rather than extracting the data to an intermediate CSV file. So as a general rule of thumb when doing this type of data migration you typically want to be using a tool like Scribe to make it happen.

Importing Data

Importing Data generally refers to a more specific one-time or ongoing requirement to import data into a live CRM environment. For example, the need to import new leads into the CRM database. Typically this is a more straight-forward "one-to-one" exercise (i.e. no data transformation required) and if this is the case, the out of the box "Data Import Wizard" can be used for this function.

One thing to note is that while the "Data Import Wizard" has advanced by leaps and bounds, it still has one chief limitation - it only can import new records. If you're looking to use the wizard to update existing records, I'm afraid you're fresh out of luck. And if that is a requirement you'll once again need to look for a 3rd party tool such as Scribe.

For an excellent general overview of the features and functions of the Data Import Wizard please refer to this post. At the end of the post it lists a number of 3rd party tools that can be used to fill the gap in functionality of the Data Import Wizard should you encounter it. Although none of these products have what I would term a "no-brainer" price. Below is a rough comparison in pricing of the various tools on the market (as of this writing):

1. Scribe: 
• $3000: 15 user license
• $5500: 100 user license
• $1900: 60 day migration license
2. Inaport: 
• $1799: standard (should be sufficient for import function)
• $3499: professional
• $1195: 30 day migration  "professional" version which is apples to apples comparison for the Scribe migrate license)
3. Import Manager (best option if end user interface is required)
• ~$2500
4. Import Tool (attractive pricing) 
1. ~$1300: Full Version
2. ~$325: 60 day migration license

The following tools don't seem to be realistic candidates based on their price point:

1. Starfish 
• $4800/year: Basic Integration
• $1495: 60 day migration license
2. eOne SmartConnect 
• $4500 (not sure if this is a one time or per year fee)
3. QuickBix 
• $7000: 100 user license ($70/user)
4. Jitterbit
• $800/month: Standard Edition
• $2000/month: Professional Edition
• $4000/month: Enterprise Edition

The following tools do not seem to fulfill the requirement:

1. CRM Migrate
• Tool specifically built for migrating SalesForce to CRM
2. CRM Sync: 
• Very little information and no pricing for this tool

CRM 2011 Document Management Settings: SharePoint Best Practice

This being a blog about Microsoft CRM it is perhaps a little bit of a reach to be discussing SharePoint best practices. But as the technologies overlap in this particular area, I think it might be worthwhile to briefly touch on some high level SharePoint best practices as those features could play in quite well with what we are ultimately driving towards i.e. a best practice recommendation in terms of integrating the 2 technologies. This post will be focused exclusively on the content management feature set of SharePoint as this is the area of integration that is provided out of the box in CRM 2011.

The way in which documentation is typically stored and classified on a File Server is by employing the use of folders. You physically stored different types of documentation in different folders in order to organize your content. This idea is still very entrenched in the thinking of most end users and is reinforced by the way in which we store content on our personal computers. Using this approach, a particular document is located in a single folder on a File Server.

SharePoint introduces the concepts of content types and metadata for tagging content. Using this approach, instead of storing content to a particular folder, you instead "tag" it to have certain defined characteristics when saving the document. The tags allow the document to be organized in different ways and the navigation can also vary depending on how the tags are grouped. By way of example, this is very similar in concept to how gmail works where instead of assigning an email to a particular folder as is the case with other email systems, you instead assign labels to the email. If 2 labels are assigned to a particular email, it can be navigated to using either of the labels. Another more immediate example is this very post which has been assigned two labels and therefore can be navigated to from each of those labels.

It should be mentioned that although SharePoint also allows the use of folders in the document libraries, it is generally best practice to avoid using them to the extent possible. This is because this feature is “retro” in terms of thinking; it also functions as a crutch to those who are more familiar with the old File Server approach and therefore may lead to bad content management practices. Having said all that, there may be valid reasons to use folders in SharePoint but generally they should be left to store imported or unstructured content.

Therefore, in summary, a much better content management practice is to leverage SharePoint content types and metadata for tagging content. Document tagging is a building block of SharePoint and can subsequently be used for many other SharePoint features such as:

• Aggregation (for content navigation as described above)
• Search scopes
• Audience Targeting
• Workflow
• Templates
• Office integration

All the above features can enable the improvement or elimination of internal inefficiencies within your organization. But that is beyond the scope of this discussion.

Previously we reached two conclusions with regards to the CRM/SharePoint configuration settings:

1. The Individual Path is a generally favored approach
2. Selecting too many entities for associating Documentation can lead to confusion and disorganization

Next we will combine the above SharePoint best practice to arrive at what could be considered to be a CRM/SharePoint integration best practice.

CRM/SharePoint integration: Best Practices

In a series of previous posts we reviewed the various settings available for configuring the SharePoint integration with CRM 2011. We started off by reviewing the primary configuration options available. We then attempted to take into consideration the pros and cons of each approach i.e. the entity based approach and the individual path. We then reviewed some SharePoint best practice considerations.

The intent of this post is to bring that all together to arrive at a general purpose recommendation for CRM/SharePoint integration.

As  has hopefully been illustrated in the series of previous posts, there are challenges to either of the SharePoint integration configuration approaches when it comes to having the SharePoint integration take place at multiple CRM levels. In addition to this, it can also been argued that this could also lead to confusion and/or inconsistency in terms of where content is stored. Conversely, we described the benefits of  using SharePoint metadata as part of a SharePoint content management best practice.

Therefore... perhaps we can keep this relatively simple in CRM while leveraging the power of SharePoint to organize the documentation? I'd venture to say that we can achieve this objective by doing as follows:

• Only create the CRM/SharePoint integration at a single level (most likely at the account or contact level).  

• Classify all content stored using SharePoint Content types. For example, we will store a quote for account ABC at the account level but give it a content type of "Quote"; we  will also store a "Statement of Work" for account ABC at the account level but give it a content type of "SOW". And so on and so forth.

By doing so, we achieve the following stated objectives:

• Keep it simple:  In CRM we have only a single location to navigate to for storing and viewing content. This also avoids the "user discretion" problem described.

• Organization: By leveraging SharePoint content types/metadata we are taking advantage of the power of SharePoint for organizing content as described in this post.

Obviously this "best practice" is not a one size fits all and there will always be other things to take into consideration based on specific customer requirements and analysis.

CRM 2011 and SharePoint Online integration

Until fairly recently (around the end of November) the ability to integrate CRM 2011 to SharePoint 2010 was limited to the on premise version of SharePoint. Which precluded SharePoint Online (as part of Office 365). Now this limitation has been overcome - you can see Microsoft's announcement here.

Configuring the SharePoint Online integration is actually a simpler affair than it is with the SharePoint On Premise version as much of the prep work is already incorporated to allow the solution to be uploaded (HTC extension scripts, permissive File Handling settings etc.). Essentially you can skip the section on "Add .htc extension to the list of the allowed file types" in the installation instructions (for configuration of the SharePoint Online version).

The only gotcha I experienced was in being able to make the "Upload Solution" appear. After navigating to Site Settings | Solutions, the resulting form told me to click "Upload" but I could not actually see an upload option anywhere.

This problem is solved simply by clicking the checkbox next to the name at which point the ribbon shows with the "Upload Solution" option. Not overly intuitive...but it works. Aside from this, the rest was pretty much plain sailing.

Dymo Printing

Need to connect your CRM installation to a custom label printer such as a Dymo printer? The following is another good example of customizing the CRM 2011 ribbon in order to the connect a Dymo printer in a context sensitive manner. We'll assume that we're integrating the Dymo printer to the CRM contact form. The end result is shown below whereby the address of the opened contact is sent to a Dymo label printer by simply clicking the "Dymo Print" icon.

So how can this be configured?

Start by using the Visual Ribbon Editor to configure the Dymo Print button on the ribbon (notice that I borrowed the icons for this from "Print Quote" icons but you could of course define your own web resource images and link to the those).

In the actions section, define a jscript function called DymoPrint and reference the jscript library where this function will live.

You can also define a DisplayRule so that the icon only shows in Existing forms (i.e. not the Create form). This makes sense as you should only be able to print once the form has been saved.

Add the jscript function to the jscript web resource indicated in the screenshot above which consists of 2 parts:

1. Concatenate the print string
2. Call the Dymo printer add-in

Note that in order for this to work the Dymo printer needs to be installed on the local computer. If this is not the case a friendly error message will be issued.

It also looks for the Label.lwl file which specifies the formatting for the print out in the 3 locations specified in the script. If you are using a different file name or this is in a different file path, you will need to update the script accordingly.

function DymoPrint() {

      var texttocopy = "";

     

      try {

                if (Xrm.Page.getAttribute("address1_line1").getValue() != null)                

                      texttocopy += "\n" + Xrm.Page.getAttribute("address1_line1").getValue();        

                if (Xrm.Page.getAttribute("address1_line2").getValue() != null)                

                      texttocopy += " " + Xrm.Page.getAttribute("address1_line2").getValue();           

                if (Xrm.Page.getAttribute("address1_line3").getValue() != null)                

                      texttocopy += " " + Xrm.Page.getAttribute("address1_line3").getValue();           

                if (Xrm.Page.getAttribute("address1_city").getValue() != null)                 

                      texttocopy += "\n" + Xrm.Page.getAttribute("address1_city").getValue() + ",";           

                if (Xrm.Page.getAttribute("address1_stateorprovince").getValue() != null)

                    texttocopy += " " + Xrm.Page.getAttribute("address1_stateorprovince").getText();           

                if (Xrm.Page.getAttribute("address1_postalcode").getValue() != null)                 

                      texttocopy += " " + Xrm.Page.getAttribute("address1_postalcode").getValue();         

                if (Xrm.Page.getAttribute("address1_country").getValue() != null)

                    texttocopy += "\n" + Xrm.Page.getAttribute("address1_country").getText();     

                var DymoAddIn, DymoLabel;

                DymoAddIn = new ActiveXObject("DYMO.DymoAddIn"); 

                DymoLabel = new ActiveXObject("DYMO.DymoLabels");

                if(DymoAddIn.Open("C:\\Documents and Settings\\All Users\\Documents\\DYMO Label\\Label Files\\LABEL.LWL"))   {           

                      DymoLabel.SetAddress(1, texttocopy);       

                      DymoAddIn.Print(1, true);

                }   else if (DymoAddIn.Open("C:\\Program Files\\DYMO Label\\Label Files\\LABEL.LWL"))   {      

                      DymoLabel.SetAddress(1, texttocopy);       

                      DymoAddIn.Print(1, true);

                }   else if (DymoAddIn.Open("C:\\Users\\Public\\Documents\\DYMO Label\\Label Files\\LABEL.LWL"))   {      

                      DymoLabel.SetAddress(1, texttocopy);       

                      DymoAddIn.Print(1, true); }  

                else   {           

                      alert("Error: Label file LABEL.LWL Not Found! Please speak to your system admin");

                }

      } catch(e) {     

            alert("You do not have the Dymo AddIn installed. This is required for printing labels."); 

            alert(texttocopy);

      }

}

CRM 2011 Document Management Settings: Select Entities

Having reviewed the pros and cons of both the Account-centric and Individual Path approach we can now attempt to start drawing some conclusions.

In short, I'd venture to say that the Individual Path approach is considered to be the overall better approach as it’s less prone to “disorganization”. Which to me is the most important factor when it comes to organizing content in SharePoint. There might be exceptions to this on a case by case basis, as it will depend – as has been hopefully illustrated – on the nature of the entity for which the documentation is being stored.

Now that we've chosen the Individual Path, the question then becomes - at which entity levels should documentation be stored? That is, as has been illustrated, you can specify to have the "Documents" tab show up on virtually any CRM entity. So you could check off accounts, contacts, opportunities, orders, quotes etc. such that any documentation pertaining to the account will be stored at that level, and any documentation pertaining to the contact will be stored at that level, and any documentation pertaining to opportunities will be stored at that level, and so on and so forth.

The issue that now becomes apparent is that of "user discretion". Let's use a "Statement of Work" (SOW) document as example. User A might consider this to be opportunity related and therefore may decide to go into the opportunity to store this document. On ther other hand User B might consider this to be more of a company document and therefore may decide to store this against the parent account. User C might be just too lazy to navigate all the way down to the opportunity and may also store it against the account for no particular considered reasoning.

Then there is the reverse scenario where User D wants to go and review the document that was stored. And discovers after searching around a bit that it is stored in a different location than a previous SOW.

An SOW is obviously just one example of this issue - but hopefully illustrates that the issue with selecting too many entities for associating documentation is that it can lead to additional disorganization and lack of consistency/standards as far as content management is concerned. The more levels selected the more of an issue this is likely to be.

Both the storage and retrieval of documentation must be as intuitive and easy as possible. In short, users should know - without having too think about it too much - where to go and store a document or conversely where to go to find a particular document.

Therefore one of the conclusions to draw here is as follows:

Do not choose "select all" for the Select Entities settings. Give it careful consideration and make sure that the entities selected are distinct enough such that it keeps it simple and logical in terms of document storage and retrieval. If you do not do so, you are less likely to benefit from the CRM/SharePoint integration due to the fact that your documentation will become less organized and harder to find. The end result being that it will decrease the chances of having this feature successfully adopted within your organization.

SharePoint itself of course has a ton of features and functions designed to better organize content. Until now, we really have focused on the CRM side of the CRM/SharePoint integration equation. However I think that the most successful implementation of this integration incorporates taking advantage of some of the key SharePoint capabilities. We'll review this next.

Next: CRM 2011 Document Management Settings: SharePoint Best Practice

CRM 2011 Document Management Settings: Not Based on Entity

It's been quite a while but previously we were reviewing the pros/cons with the various document management settings in CRM 2011. In the referenced post, we reviewed the pros/cons of checking off the "Based on entity" option when setting up the Document Management setting. This time we will review the pros/cons of leaving this option unchecked.

In the original introduction to this topic we termed this option (i.e. leaving "Based on entity" unchecked) as the "Individual Path". This is because when I store documentation using this setting, the path to the stored document will go straight from the root location to the sub-location corresponding to the name of the entity it is stored under (account, contact, opportunity etc.). As opposed to the Account Path which is relative to the parent entity in which the document is being stored and therefore for child entities will involve an additional level of navigation.

The main benefit of this approach is that it is quite simple. To find or store contact documentation, you just need to navigate to the corresponding contact in SharePoint. And also... it avoids the downsides that were mentioned in the Account Path approach.

The main downside to this Individual Path approach is that there is no connection between this and the parent account from a SharePoint navigation perspective (i.e. when navigating from the SharePoint user interface). Other downsides include:

• If the sub-contact moves to another account, then some manual steps would need to be taken to prevent the co-mingling of content from the former and current account.

• The “oops factor” is also present but to a lesser extent than in the account centric approach. For example, if a contact, opportunity etc. is renamed the SharePoint location name will no longer correlate exactly with the corresponding CRM entity it is linked to (unless manually fixed).

It should be mentioned that both of the above downsides also are present for the Account Path approach. These should be addressed either via business process or by implementing business logic to prevent these issues from occurring. For example, you could use jscript to prevent the entity name from being updated in order to prevent the second scenario from occurring.

In the next post, we'll wrap up this topic by trying to pull it all together and arriving at some implementation recommendations.

Next: CRM 2011 Document Management Settings: Select Entities

CRM 2011 Document Management Settings: Based on Entity Pros/Cons

It's been a little while but in a former post we were discussing the various configuration options that we have available when configuring the out of the box SharePoint integration with CRM 2011. And in particular, we were reviewing the impact that the "based on entity" setting has on how the content is physically stored in  SharePoint. Or as I termed it - "the centricity of storage".

I had also mentioned that we'd review the pros and cons of these configuration options and in this post I'd like to make good on that promise. In particular, I'd like to focus on the pros/cons of setting the "based on entity" to  Account or Contact. For the sake of discussion, we'll assume the Account-centric setting.


The benefit of this approach is that the content is a little bit more organized. That is, the structure of the content mirrors the structure of the customer organization and therefore it seems more logically organized to a certain extent. For example, if you had a customer portal that exposes customer documentation, it would be sufficient to link it at the account level and the remaining levels would just “follow suit”.

The main downside of this approach is that it can become more disorganized over time. Some of the contributing factors to this might be:

• Documents can be stored in different paths depending on the “characteristics” of the entity in question. For example, a contact with an account will be stored in the “..\account\SolarTech\Joe Bloggs” location, whereas a contact without a parent account will be stored in the “..\account\Joe Bloggs” location (as there is no account reference). This is perhaps the most unsettling factor as you want order to your data so that you can follow a logical predefined path for storing and retrieving data rather than having two different navigation systems depending on the nature of your data. This issue might be mitigated if the nature of the entity is such that it would always have a parent. For example, contacts in CRM could very well be parented or un-parented leading to the issue described. However opportunities should always have a parent and therefore is less prone to this type of disorganization.

• The relationship structure can change. For example (using the illustration provided in my former post), Joe Bloggs might at some point leave SolarTech and join ABC Corp. This is ok, but CRM is not yet smart enough to detect this change in relationship structure and it will be up to a diligent user (which is wishful thinking at best) to change the location under the contact rather than continuing to add content which will inevitably lead to the wrong documentation appearing under SolarTech.

• The “oops factor”. This is a variation of the above. That is, what happens if I create a contact, click on the Documents link to create the SharePoint location and then “remember” to associate a parent account to a contact? The result is that I now have the SharePoint location for this contact stored in the wrong path and as a user I need to remember to move this around. It is possible to mitigate this by creating some client side script. For example, we could hide the Documents link until an account is added but there are other scenarios that would be impossible to cover (e.g. initially parenting a contact with the wrong account). 

• Too many levels. It can also quite easily be argued that the account-centric approach introduces too many levels into the document storage structure, involving too much required navigation etc.

Next: We will need to review the pros/cons of the "individual" path approach and see if we can perhaps bring it all together by driving towards a best practice recommendation.

Lync Presence in CRM Outlook Client

My previous post highlighted some of the enhancements that Update Rollup 5 has brought to the table.


The last one on that list - CRM Outlook Client enhancements - includes fixing a pet peeve that was noticeably absent until now. Which was the lack of an integrated Lync presence on the CRM Outlook Client. This seemed to be a glaring oversight as it did work in CRM 4.0. We had logged this as a support ticket to Microsoft and the response we received was none too encouraging and I quote:

Thank you for your patience, I wanted to give an update on this.  Our Escalation Engineers have determined that this is functioning by design and will not get fixed in the current release of CRM.  This functionality worked within CRM 4.0 client because CRM data was display on web pages which allowed presence data to be displayed.  In CRM 2011, our development team opted to give CRM more of an integrated look and feel with Office, so standard Outlook controls were used.  As a result, the control in which CRM uses to display data does not support the usage of presence data.   

To implement functionality to include presence data within Outlook would require a redesign of how the CRM client displays data.  Such a redesign will not come in the middle of a product lifecycle but it certainly is possible for a future release of CRM.  Please feel free to submit this as a product suggestion to our developers at https://connect.microsoft.com/dynamicssuggestions/

Let me know if you have any remaining questions on this issue.  If you do not, I will go ahead and archive this support incident.

Anyway, this story of course has a happy ending. The support rep indicated that the enhancements would be possible in a future release of CRM. When he said that I assumed that it would be pushed out, at a minimum, to the next major release of CRM. But I guess it depends on how you define "release" and in this case it seems to be that Update Rollup is classified as a release. Either that or Microsoft development changed their mind but either way I'm not complaining.

Below is a screenshot illustrating the user experience (I couldn't get anyone else to pose so you'll have to settle for an image of moi).

Uploading files from the file server using Scribe

The Challenge
You need to upload files from a file server into CRM. A good example of this requirement might be if you're migrating from another CRM system where attachments to CRM entities are stored directly on the file system and referenced from the CRM records rather than being stored as a blob directly in the database as is the case with Microsoft Dynamics CRM. When a file is already stored as a blob in the database, the conversion is fairly straight forward. But how do you about uploading files that are stored on the file server as attachments to MSCRM records?



The Solution
Fortunately the solution is also pretty straight forward if you have the option of using Scribe for migration. As a picture is worth a thousand words, I will illustrate it with a screenshot:

In short, all you need to do is to map to the "annotation" entity and ensure that:

• isdocument = 1
• vfAttachmentFileName = path of the file on the file server

And that should pretty much do the trick.

CRM 2011 Document Management Settings

In my previous post I provided an overview of the CRM/SharePoint integration capability. For a good reference of the detailed steps that are involved with setting the basic integration up, you should refer to this walk through.

In this post, I want to focus on the primary configuration options that are available.When configuring the SharePoint integration in CRM, you have the option to define both of the following (as part of one time set up):


Level of integration

Here you can define for which CRM entities the integration will be set up. For example, you can set it up so that accounts, opportunity and contacts have a link to CRM. As shown in the screenshot below, when I store documentation for the SolarTech account, the documents are stored in the SolarTech account library in SharePoint. If I defined it to also tie in at the contact level, then we would similarly see that documentation can be stored for the Joe Bloggs contact, and would corresponding appear under the Joe Bloggs contact in SharePoint. And so on.

 “Centricity” of storage

The "centricity" can either be centered around account or contact. If you wanted to configure this option, then in a b2b world, you would most likely want to base it off "account"; whereas in a b2c world, it would be based off of "contact". We'll assume b2b for the remainder of this discussion.

Using the account and contact mentioned above as an example and assuming Joe Bloggs is a contact for the SolarTech account. I can either set it up so that whenever I store documentation it will follow the account path or the individual path

At the account level nothing changes, but at the contact level, if I store a document for Joe Blogg, using the account path, the document will be stored in a SharePoint location that looks like:

..\account\SolarTech\Doc1.doc
..\account\SolarTech\contact\Joe Bloggs\Doc2.doc
..\account\SolarTech\contact\Joe Bloggs\Doc3.doc
..\account\SolarTech\contact\Ed Rogers\Doc4.doc

Conversely, if I store a document using the individual path, the document will be stored in a SharePoint location that looks like:

..\account\SolarTech\Doc1.doc
..\contact\Joe Bloggs\Doc2.doc
..\contact\Joe Bloggs\Doc3.doc
..\contact\Ed Rogers\Doc4.doc

In summary, the former approach centralizes the path around the parent account whereas the latter has no correlation to the parent whatsoever. The same would be true for any other entity related to an account (e.g. quotes, opportunities etc.)

In my next posts I will be reviewing the pros and cons of these configuration options that you will want to take into account before making your design decision.

Next: CRM 2011 Document Management Settings: Based on Entity Pros/Cons

CRM 2011/SharePoint Integration Overview

One of the most compelling features for upgrading to CRM 2011 is the tight "out of the box" integration that CRM has with SharePoint 2010. While it was possible to integrate CRM with SharePoint in previous versions, that involved developing a custom solution. Whereas in CRM 2011 the built in integration capabilities offers a nice, clean way of integrating these two applications and provides a great alternative for document management directly through the CRM user interface.

To some extent this integration is the one of the "holy grail" enhancements that we have been eagerly awaiting... for a very long time. The problem has generally been that while CRM has the ability to store documentation in attachments, it is by no means a "document management solution". And trying to leverage CRM as a document management solution is trying to fit a square peg into a round hole. On the flip side, we have this other great technology solution called SharePoint which among multiple other capabilities is a very strong platform for content and document management. So in 4.0 while there were various creative ways of handling the document management conundrum within CRM, they were just that - workarounds...

CRM 2011 is only part of the requirement for this integration solution. You will of course need to have or upgrade to SharePoint 2010 in order to be able to leverage this out of the box capability. SharePoint Foundation 2010 is available freely with the purchase of Windows Server 2008 which should make this option very feasible. Of course, if for whatever reason your organization does not want to use SharePoint 2010 or is not ready to upgrade to that environment, you will need to fall back to one of the creative solutions.

It should also be mentioned that the CRM/SharePoint out of the box integration only offers integration between CRM entities and SharePoint libraries in it's current incarnation. Meaning - it does not currently offer integration between a CRM entity and a SharePoint site. The good thing about integrating at the library level versus the site level is that it does tend to keep things nice and simple. But I can understand that there may be some situations where it would be preferable to connect at the site level and if that's your requirement... well, for now, you're fresh out of luck. At least using the out of the box option that is... As the CRM and SharePoint are in my opinion strategically aligned solutions, I would expect to see the level of this integration to deepen in future versions/upgrades of these products and wouldn't at all be surprised to see an integration at the SharePoint site level at some point. But that is purely based on my subjective view of the world. Time will tell if that prediction pans out.

While the integration between these two solutions is out of the box, there are various options in terms of configuring how this integration can be set up. I will outline these options in follow up posts and suggest some best practice considerations for configuring them.

Next: CRM 2011 Document Management Settings

CRM 4.0 Explorer View

Ever faced the dilemma of knowing where to store/find your documentation? For more advanced document management features, we would recommend a Sharepoint integration methodology (in CRM 2011 it is a no brainer to use the SharePoint integration as that comes out of the box, but if for some reason you do not have SharePoint 2010 - SharePoint Foundation is free so there really should be no reason - you can follow this approach in CRM 2011 too although it will need some adaptation). But for those who have simple needs or have a smaller budget for solving such problems, the Explorer view provides a very simple straight forward solution to this problem. The screenshot below illustrates this concept. Users can navigate and update documentation right from CRM just as they would with Windows Explorer (identical user experience).

The following will step through configuration of the option (you can download referenced files from here):

ASPX Configuration

Create a shared folder root on one of the servers (e.g. \\<server>\CRMFiles). Make sure you grant the necessary access permissions. It is recommended that the root share location be a folder without spaces in the name.

Create a subfolder called "Test" under the root folder:

Open default.aspx and make the following changes (pay close attention to the number and placement of the “\” character):

• On line 20 update the “src” tag to point to the correct share location (src=\\<server>\CRMFiles\)
• On line 21 update the “ddf_src” tag to point to the correct share location (ddf_src="\\\server\CRMFiles">)
  

Copy the modified file from above to the \crmweb\ISV\Sentri\Explorer location on the CRM server:

Test the above by trying to connecting to your test folder:

http://<server>:<port>/ISV/Sentri/Explorer/default.aspx?FolderName=Test

If you do not get an explorer view returned similar to the above, you have made a mistake in the deployment steps – please review the steps until you get a successful explorer view returned.

CRM Entity Configuration

On the CRM entity where you wish to configure the Explorer to appear you will need to make the following changes.

Add an IFrame to the form with a name of IFRAME_DOCS (note this name can be anything but it must match the jscript code – see later in this document).  The recommended settings are shown in the screenshots below.

Open onload.js and make the following changes:

• On line 5 update the logic for setting the folder name as necessary (see configuration section for more about this)
• On line 6 update the share location (var netshare = "\\\\server\\CRMFiles\\";)
• On line 7 ensure the url points to the correct path (should be if you followed the deployment instructions above)

Copy the onload.js into the form load event – you will need to ensure that the “fileshare()” function is called from somewhere in the onload jscript.

Configuration

In above implementation, there will need to be folder names under the share root matching the account name (assuming the jscript in  loaded in the account form). This of course can be modified as necessary to suit implementation requirements.

CRM 2011 Mashups

Earlier I provided an introduction to mashups in CRM 4.0 including downloads and instructions on how to configure this in your CRM 4.0 environment. This topic then segwayed into a discussion about integration approaches one of them of course being the mashup/virtual integration approach.

It's time now to come full circle and discuss how the mashup/virtual integration can be configured in a CRM 2011 environment. With the new configuration options provided by CRM 2011 it is no longer necessary to refer to an external redirection web page in order to accomplish the objective (using the Navigation Pane). We will step through this example by creating a mashup between a CRM account and a bing map (arguably the most "classic" of mashups).

• Navigate to Settings | Customizations | Custome the System | Entities | Account | Forms and open up the Main form

• Click on the Navigation icon. After clicking this the left navigation panel is enabled. 

• Navigate to Insert | Navigation Link and in the resulting dialog provide a Name and an Icon (none of the other fields need to be filled in - they will be provided at run time using jscript manipulation)

• Save and Publish the form
• Open an existing account, hit Ctrl+N to open it so it does not appear in application mode and launch the IE Developer Tools
• Search for the "Map" navigational item and when you locate it, copy the "navLink" item from the "id" attribute

• Copy the script below and replace the navlink id with what you copied in the above step

function Map() {


var addresr1        =Xrm.Page.data.entity.attributes.get("address1_line1").getValue();
var addresr2        =Xrm.Page.data.entity.attributes.get("address1_line2").getValue();
var city            =Xrm.Page.data.entity.attributes.get("address1_city").getValue();
var state           =Xrm.Page.data.entity.attributes.get("address1_stateorprovince").getValue();
var postalcode      =Xrm.Page.data.entity.attributes.get("address1_postalcode").getValue();


if(addresr1==null)
{
addresr1="";
}
if(addresr2==null)
{
addresr2="";
}
if(city==null)
{
city="";
}
if(state==null)
{
state="";
}
if(postalcode==null)
{
postalcode="";
}
var parmval=addresr1+" "+addresr2+" "+city+" "+state+" "+postalcode;


var navAcctVal = document.getElementById("navLink{4527a3a5-4173-43b8-3a08-da7da29a1ac2}"); 
if (navAcctVal != null && navAcctVal != undefined) 
{ 
var u1 = encodeURI("http://www.bing.com/maps/?v=2&where1="+parmval); 
navAcctVal.onclick =function () { loadIsvArea(Mscrm.CrmUri.create(u1), true); }; 
}


}

• Link the "Map" javascript function to the main form load event and publish
• The next time you load an account and click on the Map link, you should be able to see a context sensitive bing map linked to the account you are reviewing

Integration Approaches - part 3

In my previous post I discussed the second integration approach - that being virtual integration. This post will cover the third integration approach available.

In truth, this third integration approach is in essence a variation of the second integration approach which is why I mentioned at the outset that there are in fact only 2 high level approaches to integration.

This third approach leverages reporting capabilities in order to combine CRM with data from other systems. In many cases - especially when dealing with back office ERP or accounting systems - the application front end is a windows form application. That is, there are no URL-addressable pages that can be linked to in order to leverage the second virtual integration approach.

In such a case - if physical data integration is not on the cards for the same reasons as have been mentioned in my former post - then this reporting integration approach is likely the way to go.

The idea behind this approach is that if a standard report can be written to retrieve the data from the remote application database and be formatted and laid out as necessary, it can then be linked to CRM using the virtual reporting integration approach. This of course only holds true provided that the reporting tool you are using renders the report in html format. The best option for this approach is to use Sql Server Reporting Services (SSRS) while adhering to the CRM SDK standard for writing reports to target the Microsoft CRM platform (and using remote joins to connect to the remote database). By doing so, your report can be embedded into a CRM form and with a little bit of formatting the data can even be made to appear as if it resides natively in CRM.

You can refer to the following article for a step by step guide on how to leverage this report level integration option.

Integration Approaches - part 2

In my previous post I mentioned that there were essentially 3 integration approaches and discussed the first one - physical data integration - in depth. I will continue with the second type of integration approach in this post.

The second approach to integration is virtual. I have already addressed what this approach is all about while discussing the concepts of CRM mash-ups and therefore I'll not delve too much further with regards to this approach. This type of integration is a relatively new integration approach that is made possible through web technologies and URL-addressable forms.

This approach should therefore be used when linking to another application that can be accessed via a URL and linked in a context sensitive manner to the account, contact, etc. entity being viewed. It is the obvious (and perhaps only) choice of integration when integrating to a web page somewhere on the internet as illustrated by the Google map sample. However it is also a valid option as an alternative to the physical data integration approach especially when the volume and size of data being integrated to is large. As a rule of thumb, if none of the requirements for physical data integration exist (as listed in my former post) and the option for this virtual type is available (i.e. the application/web page is URL-addressable), then this type of virtual integration should be strongly considered as a method of application integration.

I'll address the third type of integration approach in my next post.

Integration Approaches

My former post explained how to go about using the "mash up" technique for integrating CRM with other applications. In so doing, it also touched on other approaches to integration. I thought I'd delve into that topic a little more in this post.

In essence I mentioned that there are 3 high level approaches when it comes to combining two applications together. Although technically - when it comes to it - there are in fact only 2 high level approaches to integration. But we'll come to that. This topic is not limited to Microsoft CRM but can apply when integrating any two systems together.

The first approach is physical integration. That is, data in one system is physically moved to another system. This is perhaps the most common form of integration and is most often what people think of when they refer to the term "data integration". Of course there are many different methods of going about physical data integration be it real time integration, close to real time integration, batch integration, and file imports/uploads. And there are various mediums/formats that can be used for integration such as web services, XML, CSV, stored procedure, direct database querying/updating and so on. But at a high level these all represent a single approach to integration - that being the physical transfer of data from one system to another. Perhaps at another time we can perhaps delve into these different methods, mediums and formats for integration highlighting pros/cons to each of them and when they may or may not be appropriate.

Physical integration is required in any one of  the following use cases:

• Data Continuity - The data starts in one system and needs to be "embellished" on via the CRM user interface and perhaps passed back to the original application to form a 2-way integration or onto another application.
• Data Accessibility - Sometimes data needs to be updated in 2 systems because that's just the requirement. For example, accounting personnel will need to update an account record in the back office accounting system and the sales team will be updating the same information (perhaps with checks/balances) via the CRM front end.
• Reporting - Data needs to be reported on from within the CRM database
• Workflow - Data brought into CRM is used to trigger workflows. For example, an escalation or approval workflow being triggered off an account billing status.
• Offline requirements - If the data is required offline then it will need to flow into CRM in which case, CRM's syncing capability with Outlook can be used to bring the data offline 
• Mobile requirements - Similar to the offline requirement. If the data needs to be synced with a mobile application it will need to be passed into CRM.
• Security - Not a very common scenario, but if the data coming in has security restrictions in terms of who can view it, then CRM's security model can be applied against it if the data physically resides in CRM.
• No other way - It could be that the source system is not accessible by any other means than via data integration. This could be if the application has some flat file format, is stored in a spreadsheet, or some other variation that makes connecting to the information through any other means other than data extraction/integration impossible.
  

Physical integration may not be a good idea in the following scenarios:

• Size of data - If the data on the other side is very large (in the millions, tens of millions and beyond) or changes very rapidly it might be unwise to do physical data integration due to the volume of information that will constantly be flowing back and forth. This could be true of invoices or supply chain information.
• Simplicity - Physical data integration may just not be necessary or it might be simpler to use a different approach either for the short term effort or long term maintenance effort or both. Remember that integration is something that over time needs to be maintained and if having a more "static" approach will work then this may be the better option.
• Tools - If you don't have the right tools for integration and have budget restrictions in that regards then you should probably look into other alternatives.

As alluded to by the last point above, when physical integration is required then you are best off ensuring that you have the right tools for the job. I have already discussed this topic in depth  a former post in case you want to get a perspective on this.

I will discuss the other integration approaches in separate postings.

CRM 4.0 Mashups

In CRM 4.0 we have the ability to create "mash ups" in order to combine CRM with other web applications. This essentially creates a visual integration between CRM and the other application such that an end user does not necessarily know where one application begins and the other one ends. This "graying" of the application boundaries is a good thing as at the end of the day, an end user should be prevented from having to access silos of information in favor of having a single access point for all relevant business data. Be it, native CRM data, physically integrated accounting data, or visually joining the applications as in this case.

This kind of integration could be achieved by either employing the use of an I-Frame approach or by adding a link to the Navigation Pane. Although there are cases where the I-Frame approach is justified, generally the Navigation Pane approach is better as it is more visually appealing and provides better use of the screen real estate.

There are many applications for this type of integration:

• It can be used to pull relevant information from a web page (msn, google, yahoo etc.) and have it presented to the user when they access an account. 
• It can also be used to accomplish virtual integration with another business application. For example, instead of physically bringing over invoice data from your back end accounting system into CRM for access via your front office, you could integrate the applications virtually by means of this approach. 
• You could integrate reports into a form to provide graphical, summary or other displays of information that cannot be achieved through other means. Alternatively if say your accounting data, is not accessible via URL, you could create an SRS report on the data you wish to view and combine it with your CRM form.

Below is an example of the first of these i.e. a mash-up between a CRM account and a Google map. The map is context sensitive to the address of the account and when the "Map" link is clicked it will show the address of the account on the map. The same is true for the News and Stock links shown in the screenshot.

You can download the files and instructions for configuring this in the Navigation Pane in the 4.0 environment from here.

Scribe Online

Scribe Online is Scribe's latest product offering. The current offering is limited to work with Microsoft CRM and basically allows for a CRM Online solution to be replicated locally. The value add of such a solution is perhaps a little less obvious than Scribe's flagship offering: Scribe Insight. Simply put - whenever you are entertaining the notion of building any sort of integration with Microsoft CRM (or for that matter standalone databases, or any of the other Scribe templates such as GP, Salesforce etc.), Scribe Insight is going to have to be one of the options considered for accomplishing this. The benefit of using a tool such as Scribe Insight over say, a custom built solution, is fairly substantial and I've reviewed some of the considerations in a former post.

The Scribe Online Replication Service though has - at least to me - a somewhat less obvious niche.

First and foremost, this offering is not meant to be a backup solution which - in fairness - Scribe has made fairly clear. Although CRM Online cannot be backed up as you could for say an On Premise implementation, I think that it has to be kind of axiomatic of the cloud model that your data is secure (I'm sure Google and SalesForce would agree...). Having said that, it could provide companies with a "sense of comfort" that their online data is also available locally. But I personally would not encourage that type of thinking as it goes against the kind of thinking that is necessary in order to move into the cloud.

I think it can also be argued that Scribe Online's Replication Service is perhaps a little anachronistic in that it kind of defeats the purpose of going online in the first place. The major driver for going to CRM Online in the first place is so you can subscribe to the SaaS model and not have to deal with servers, environments, maintenance etc. But yet - here we have Scribe Online that will require you to have a local server with SQL installed in order for it to work...

If so, I think it is fairly clear that the Scribe Online Replication Service is going to be required in a given number of scenarios. So what are these? Below I will attempt to outline where I think such as service can come in handy which is based both on my own considerations and information garnered from Scribe demos:

• Reporting - As highlighted previously, reporting in CRM 2011 Online is significantly more robust than it was in 4.0. And therefore for most companies - at least initially - you should be able to handle the reporting requirements that you have using the CRM Online model. But what if you have sophisticated reported needs? Or better yet - what if you want to create a data warehouse that you can use for setting up Key Performance Indicators (KPIs) to enable you to slice/dice your data in various ways that you cannot do using your operational database (i.e. CRM Online)? Such reporting is typically a more sophisticated requirement to see trends, perform data mining, etc. in order to analyze your business. In such a case, Scribe Online can be a perfect complement to your CRM Online offering allowing you to bring the data into your local environment where it can be combined with Business Intelligence (BI) tools to deliver the goods. I believe that Scribe may also be looking at partnering with BI vendors that may facilitate the delivery of pre-packaged metrics or something along those lines. Time will tell...

• Data Cleanup/Import etc. - Another use could be if you have a need to clean up (e.g. de-dup) your production data but do not want to do it in the live environment. This requirement combines the capability of Scribe Insight with Scribe Online Replication Services. Using this approach, you could bring your data to a local environment, perform all the clean up in that environment, and when you're done you could use Scribe Insight to update your production data.

These are the major benefits that I can think of right now. And based on this, I believe Scribe Online only has value when using CRM Online as opposed to Partner Hosted. With the latter, although your data is still "online" you typically will have more access to your environment, database etc. than in the pure online model. I think it also bears mentioning that the cost of Scribe's Online Replication Service is fairly nominal at $99/month which makes it that much easier to take the plunge should you wish to experiment.

It's still very early days with regards to Scribe's Online offering and the Replication Service is only the first offering using this platform. It will therefore be interesting to see where this product heads as more capabilities get added. For those who want to know more about the strategic direction of this product, you can review Lou Guercia's (Scribe's president and CEO) interview with IT Business Edge.