I posted a short note recently on Integrating SharePoint and Dynamics CRM. The article was pretty short, mainly it introduced a recording of a session I gave recently on the topic, and I thought I’d expand on it here. The recording illustrates some of the ways you can integrate Dynamics CRM 2011 with SharePoint 2010, with a best-tool-for-the-job approach: Dynamics CRM for highly structured relational data, SharePoint for document management and collaboration.

Specifically, what I showed was how to do SharePoint document management from the context of CRM records like accounts and contacts. Even more specifically, the functionality I showed was the ability for CRM 2011 to automatically create document locations (libraries and folders) and associate them with CRM records.

This is definitely a CRM-centric integration technique: theoretically, your entire experience with SharePoint could be from the context of a CRM account form. Not that I recommend this 100% CRM-centric approach to the SharePoint experience…but if you take it, at least you’ll never forget where your documents related to that Acme account are.

Of course nobody uses SharePoint like that, but the extreme example illustrates an important point: the highly structured data in Dynamics CRM makes finding things relatively easy. CRM’s might fail, but it’s generally not because your users can’t find an account record! SharePoint’s at the other end of the data structure spectrum: the ease with which you create stuff is also what can make it hard to find.

That’s why a term like taxonomy (from Wikipedia, “the practice and science of classification”) is more important in SharePoint than in CRM: from the user standpoint, SharePoint data are inherently unstructured and need a well-defined taxonomy to impose the structure appropriate for your organization. In Dynamics CRM the “taxonomy” is implicit and hard to avoid: start at the top of the stack with the customer entities (account, contact), and it’s 1:N relationships all the way down.

CRM-Centric SharePoint Integration using the CRM 2011 List Component for SharePoint 2010

If you really want to be “customer-centric”, the integration approach the recording demonstrates will definitely help. In fact, it imposes an account- or contact-centric taxonomy on SharePoint in a very concrete way, which I’ll outline here.

But first, the technical requirements:

• Dynamics CRM 2011 (Online or On-Premise, both work fine)
• SharePoint Server 2010 (On-Premise only for now)
• Dynamics CRM 2011 List Component for SharePoint Server 2010

The list component must be installed on your on-premise SharePoint Server 2010. Once it’s installed on a site, you can point your CRM 2011 organization to the site and walk through the (taxonomy) configuration from Dynamics CRM 2011. You can select an account-centric or a contact-centric taxonomy. Here’s what it looks like if you select Account to base your folder structure on:

Note: if you read the Document Management Settings dialog carefully, it tells you exactly how the account-centric taxonomy is going to work: CRM 2011 will create document libraries in the SharePoint site for account, as well as for any other entities for which you’ve enabled document management. And if you’ve enabled document management for child entities of account, sub-folders will be created in SharePoint corresponding to child records for each account.

After walking through the rest of the wizard, here’s what the SharePoint site looks like:

You can see the Dynamics CRM entities – Account, Invoice, Opportunity, Product, Project (yes, custom entities are supported as well), Sales Literature, Service Activity – interspersed with SharePoint document libraries like Shared Documents.

Once configured, the user experience is simple: on an account form, click Documents. If a folder hasn’t yet been created for an account, you’ll be asked if you want CRM to auto-create one for you. Once created for an account, any documents added to the folder – regardless of how they’re added — will simply be there, ready for contextual access from the account form:

Which Brings Me to…

The more I use this CRM-centric SharePoint integration, the more I like it. It’s simple, makes it easy to find SharePoint content related to CRM records, and if you’re customer-centric it works like a charm. And although this strict CRM-centric taxonomy is imposed on a SharePoint site, it doesn’t need to be imposed on all your SharePoint sites. Imagine pointing your CRM organization to a “Customer”, or “Sales” site in your SharePoint site collection. That site could be your CRM-centric site, could be accessed either via CRM account forms or directly through SharePoint. Other sites in your site collection can be independent of CRM with whatever taxonomy you choose to use for them.

SharePoint-centric users and CRM-centric users both do what they do, and everybody gets along.

Up until now I’ve been talking about SharePoint Server 2010, specifically the on-premise version since there is no cloud version of SharePoint 2010 yet. (The current version, available in the Business Productivity Online Suite – BPOS for short – is SharePoint Server 2007.) The early announcements of Office 365 were generally greeted with breathless anticipation…which would be well-deserved from a CRM standpoint if we were going to get sweet integration features like the one I’ve described here.

And sure enough, the implementation of SharePoint Server 2010 in Office 365 looks great: I signed up for my beta last weekend at http://www.microsoft.com/en-us/office365/online-software.aspx and the provisioning experience was almost as good as that for CRM Online. In ten minutes my brand new SharePoint Server 2010 was up and running!

Unfortunately, in fifteen minutes I learned that the list component is not supported for the online (Office 365) version of SharePoint Server 2010! Ouch: http://community.office365.com/en-us/f/153/t/1965.aspx

Hard to believe Microsoft would ship the first big version of the cloud-Office of the future, offering precisely the same support for Dynamics CRM 2011 as you’d get, say, in Google Docs, but unless I’m misreading the tea-leaves, that’s what we’re gonna get.

Come on, guys, say it ain’t so!

Lovely day in Springfield. Cecil Renshaw, proprietor of http://www.sharepointbiz.com/Pages/default.aspx, put on an excellent show today at Erin’s Pavilion (http://www.microsoftsharepoint.info/MSEvent2011.htm). Cecil talked me into giving three presentations, and since I knew I wouldn’t remember anything I talked about, I figured I better record as much as I could.

My session 2 was a drill-down on a couple of techniques to integrate Dynamics CRM 2011 and SharePoint 2010. I’m a CRM guy for the most part, so these are definitely of the CRM-centric variety. Here’s what’s in the demo I recorded:

• The first part is about setting up and using the Dynamics CRM 2011 List Component for SharePoint 2010. (and that’s the short version of the product name!). This is brand-new functionality, and requires CRM 2011 and SP 2010 with the List Component installed.
• The second part is about contextual search of a SharePoint site from a Dynamics CRM record (e.g., account). This approach has been around a while: use an IFrame on a CRM form, and use form script to update the source of the IFrame with a SharePoint search URL. What’s new and interesting about this piece is the new Xrm.Page object model you need to use in CRM 2011 form script. The code’s kind of hard to read in the video, so here it is (on the change event of an option set field), with the base URL for the SharePoint site hardwired in this case to my company’s site. (After the code, the video)

function DisplayWebSiteInIFrame()
{
 if (Xrm.Page.getAttribute("rgk_website").getSelectedOption().text != null) {

   var selectedwebsite = Xrm.Page.getAttribute("rgk_website").getSelectedOption().text;

   var IFrame = Xrm.Page.ui.controls.get("IFRAME_selectedwebsite");

   var Address = Xrm.Page.getAttribute("address1_line1").getValue();
   Address = Address + " " + Xrm.Page.getAttribute("address1_city").getValue();
   Address = Address + " " + Xrm.Page.getAttribute("address1_stateorprovince").getValue();    

   switch(selectedwebsite)
   {
      case "SharePoint" :
         IFrame.setSrc("https://sp.magenium.com/search/Pages/Results.aspx?k=" + Xrm.Page.getAttribute("name").getValue() );
         break;

      case "Bing Maps" :
         IFrame.setSrc("http://www.bing.com/maps/?q=" + Address);
         break;
   }
 }
}

Enjoy:

At the August meeting of the Dynamics CRM User Group (www.DynamicsCRMUserGroup.com ) we held our second session on Mobility Solutions for Dynamics CRM. Microsoft’s Bob Piskule presented on the Microsoft product, Mobile Express; and Ben Mitchell presented on TenDigits’ flagship product, Mobile Access.

Here’s the introduction I gave, with some background on why “mobile CRM” matters, and of course a gracious introduction to our awesome presenters:

Bob Piskule on Microsoft’s Mobile Express

The redoubtable Bob Piskule of Microsoft (bob.piskule@microsoft.com ) gave a nice presentation and demo on Microsoft’s product, Mobile Express. This is an entirely server-based free add-on to the Dynamics CRM 4.0 on-premise product. As you will see if you compare it to TenDigits’ product, it’s got a lot of the features that characterize these “all server, thin client” approaches to mobile CRM:

• It’s inexpensive (free, in fact)
• Easy to deploy (all you need is a browser)
• Does not leverage any mobile device-specific functionality (browser only!)
• Somewhat limited, baseline feature set

Here’s a link to Bob’s presentation: Bob Piskule on Microsoft Mobile Express for Dynamics CRM 4.0.

Ben Mitchell on TenDigits’ Mobile Access

The TenDigits product (www.TenDigits.com ) is, in my opinion, the most impressive mobile solution we’ve seen in our DCRMUG CRM Mobile So-Hot Summer series. It’s really at the opposite end of the spectrum from Mobile Express and the SoftBridge Bridge2CRM product:

• It’s a “rich client” solution, meaning you need to install code on and download data to the mobile device; definitely not a browser-only solution.
• It costs more.
• It exploits native functionality of the various mobile devices it runs on.
• It has a lot more functionality.

So while there’s a price to pay for all the functionality, it will probably be a good tradeoff for people who spend a lot of time interacting in one way or another with CRM data via their mobile device.

To paraphrase Bob Piskule, for users needing infrequent or “casual” access to mobile CRM, the thin client approach will probably be fine. But if you depend on mobile CRM day in and out, the rich client approach will be the way to go.

I have not used Mobile Access yet, so I can’t provide a thorough review. [For me, iPhone support is a hard requirement, and TenDigits isn't quite there yet...] But until I can, here are two of my favorite Mobile Access features:

• They’ve built a custom workflow action, so you can build a standard CRM 4.0 workflow that sends what they refer to as a “Smart Actionable Alert” to a user with a mobile device. In the example Ben showed, the mobile user would get a popup notification on the BlackBerry, with configurable alert text and a link to the “regarding” CRM record (like an account record that had just been placed on credit hold).
• They tap into the native functionality of the mobile device to make “doing CRM” a more natural extension of the mobile experience. So rather than having to explicitly navigate to CRM on the mobile client, you just send an email or make a phone call, the way you normally would. Then, an extra option shows up on the mobile device menu, allowing you essentially to attach the activity to a “regarding” record in CRM.

I want Mobile Access! (But not enough to give up my iPhone!)

Here’s the link to Ben’s presentation on MobileAccess from TenDigits.

Full disclosure: I recently wrote this class for Microsoft. So I suppose I’m not exactly disinterested…but I actually do think it’s an excellent class and I suspect readers of this blog will be interested in it. So here’s the official landing page on the Microsoft Learning site for Course 80141, Integrating Microsoft Dynamics CRM 4 and Microsoft Office SharePoint 2007

If you’re a more or less regular reader of the Trick Bag you’ll know this is one of my favorite topics. I’ve written more than a few articles on this blog about it; you can see them all by selecting  ”SharePoint” from the Category drop-down on the right-hand side nav bar.

The course (and the accompanying book) has a “right tool for the job” theme:

• SharePoint’s sweet spots are content and document management, collaboration, enterprise search, and internal/external web sites.
• Dynamics CRM ships with out of the box support for sales force automation, marketing and service management; but where it really shines is as a platform for relational database applications.

Both are web server applications and can support an entirely browser-based user experience.  

Why Integrate?

SharePoint’s sold a lot more licenses than Dynamics CRM,  partly because it’s been in the market longer, and partly because it’s got a broader, more general purpose feature set.  Enterprises rolling out SharePoint will often deploy it to all or most of their desktops; Dynamics CRM tends to be more specifically deployed to sales, marketing and service areas.

CRM data are highly structured: so-called “entities” (accounts, contacts, leads, activities…) are related to one another, referential integrity is enforced, etc. SharePoint data are much less structured. Probably the most common use of SharePoint is to store documents in document libraries. Meta-data is typically used to describe those documents. You might have columns in a document library for “account” and “document type”, and since SharePoint is so good at search, this would make it easy for a user to get a list of all the proposals ever created for the Acme account. And even in small organizations, it doesn’t take long to accumulate hundreds of documents – P.O.’s, proposals, statements of work… —  relating to a single large account.

An example like this sheds light on one of the most useful integration points: SharePoint data as meta-data about Dynamics CRM records. Picture a Dynamics CRM account form with a tab for “SharePoint Search” which a user can click and see all or some of the documents stored in SharePoint that are related to the current account record. Once I started thinking of SharePoint as a repository of data about important CRM records I was surprised how often I came across requirements for this functionality.

• Here’s a more complete article on the general topic, accompanied by a video.
• Here’s an article specifically about how to implement SharePoint search from a Dynamics CRM account form.
• Here’s a Channel 9 video on the general topic of integrating SharePoint and Dynamics CRM

I’d be interested to hear about your experience in this area.

Also: the courseware is good foundation content for custom workshops during which I train your team in the process of designing and building your integration solutions.  Let me know if you have questions — like I said, it’s one of my favorite topics!

Richard Knudson
richardk@imginc.com

Inside View is an amazingly useful tool. It’s a subscription web site that aggregates up a number of marketing/prospecting databases (jigsaw, hoovers, D&B, zoominfo). They’ve got a great pricing model, the tool can sit inside an IFRAME on your Account or Lead forms, and if you need to prospect, I highly recommend you check it out. (And if you don’t need to prospect, please tell me  how you do it!). In a minute I’ll tell you the funny story about how I learned to use it, but first, why it’s the ultimate CRM mashup.

Here’s how it looks embedded in an IFRAME on an Account form:

It’s got seven tabs. “Analysis” and “Key Info” (showing) provide basic account information, and the other five aggregate information from lots of different databases to show them in context. Inside View has deals with all of those databases (some of which I mentioned above but there are lots more), so as long as you subscribe to Inside View, you don’t have to individually subscribe to all of the other ones.

You can probably guess what the other tabs expose, but I’ll show you the “Buzz” tab since it’s one of my favorites:

It might be a little hard to see, but the Buzz tab is a search on the account name exposed as a Twitter feed. To test it, I loaded up one of my favorite account records, switched to a Twitter session and tweeted something about the account, then switched back to the account form, refreshed, and there it was –  pretty cool! You can even see the account’s web site traffic courtesy of Compete.com. (the numbers are in thousands of unique visitors — www.kraftfoodscompany.com gets a view more visitors than the Trick Bag!) 

Prospecting with Inside View

There’s a free version I’ll tell you about below. I tried it, liked it, and purchased a subscription. A single seat subscription is $99/month, which might sound like a lot until you realize you get unlimited exports from Inside View’s account and contact/lead database. Most of the other prospecting databases I’ve subscribed to have a pay-per-lead model, or an unlimited subscription that’s much more expensive than $99/month.

You can search in lots of different ways to identify prospects; for me the best option has been to identify people with specific job titles (e.g., CRM Project Manager) at specific accounts. After identifying the records, you can export them to a CSV then import into CRM.

I’m jealous of the SalesForce.com integration, since they can do an automagic import, no CSV file required! The Inside View people tell me this is coming soon to the Dynamics CRM version — I hope so!   

How it Works

One of my sales reps received an email from a rep at Inside View a couple weeks ago. I copied and pasted the following text from it:

———————————

 Customize Account Entity 

• Double-click “Account”
• Click “Forms and Views”
• Double-click “Form” (The main application form)
• Click “Add an IFRAME”
  • Name: INSIDEVIEW_ACCOUNT_CONNECTOR
  • URL: javascript:false
  • Check the box for “Pass record object-type code…”
  • Label: InsideView
  • Check the box for “Display label on the form”
  • Uncheck the box for “Restrict cross-frame scripting”
  • Section: Account Information
  • Click “Formatting” tab
  • Scrolling: Never
  • Uncheck the box for “Display border”
  • Leave all other default values and click “OK”
• Click “Form Properties”
• Select “OnLoad” event and click “Edit”
• Check the box for “Event is enabled”
• Copy and paste the code provided for the Account connector (I’ll email you the code if you fill out the form I link to at the end of this article)
• Click “Save and Close”

From the “Customize Entities” view, select “Account” and click “Publish

———————————

In the normal course of events, I’m not able to lift perfectly good blog copy from an email, and I have to admit, seeing these perfectly good instructions on how to customize the Account entity in an email to Kim prompted me to check her security role and make sure she wouldn’t actually be able to DO this. She can’t, and anyway she has the good sense not to try it, but I thought it was interesting that somebody would send a sales rep instructions like that!

Anyway, those are your step-by-step instructions if you want to try the free version out on your own CRM — works with both CRM Online and on-premise. The free version gives you the same sweet integration, but you don’t get to pull contacts & some other things you’d expect to have to pay for. All you need to get it to work is the jscript code that goes into the Load event of your account form. The Inside View people will send it to you, but I checked with them and they said it was OK if I did also.

So, to get the Account form Load Event code for my current pick as the Ultimate CRM Mashup, click here and fill out the form.

• Various definitions of ”the market” are essentially arbitrary, and share measures will be highly dependent on these definitions.
• What are the important metrics? Revenue? Seats? Server licenses? Different vendors have different licensing models, and when you throw open source into the mix, traditional measures might miss important trends. (If you measure blog platform market share by revenue, Microsoft’s probably the leader, but there are a lot more WordPress blogs out there than SharePoint!)
• Other than as a warning indicator if the vendor you’re using drops to 0% or thereabouts, it probably isn’t a good way to decide on a platform anyway!

Here’s a good article that addresses the “does market share matter?” question in more detail: Chris Selland’s article on market share.  

I think the best reasons to care about market share are that it’s fun and interesting. In that spirit, the numbers in the following table are from the Gartner 2007 CRM market share report. Just for fun, the default sort is alpha by vendor name, but you can click columns 2 or 3 to sort, respectively, by the Gartner estimates of share and revenue growth rate (from 2006 to 2007).

[table id=1 /]

(In column 2, btw, the numbers in parentheses are revenue in thousands of US $, and estimated share.)

To me, these numbers seem reasonable:

• I’d expect SAP and Oracle to have leading shares, and also to be growing their revenues, but slowly enough to be losing share.
• When the “Others” category has a 40% share, that’s a market in flux, possibly ripe for consolidation.
• SalesForce.com and Microsoft are small players overall, but look at those growth rates!  

I’ve never been one to shy about reaching conclusions based on very little evidence, so here’s my impression of the CRM market. In 18 months, Microsoft and SalesForce.com will be contending for share leadership. Apart from both having good platforms, each will get there in its own way:

• Microsoft will leverage the partner channel the way it always has. I’ve seen it the last couple of years in the investments they’ve made in partner training and certifications, and the enthusiasm with which the partner community is adopting the Dynamics CRM platform.  
• SalesForce seems to me more like Apple, with its direct sales model, and the vibrant AppExchange being to SalesForce.com what the App Store is to the iPhone.  

But as I said, I’m skeptical about market share. It’s market leadership that matters. And I want to know what you think. So in that spirit, please fill out this simple two question survey, and we’ll come back to this in 18 months and see how we did.

I used my editorial judgment and added Sugar CRM (www.SugarCRM.com ) and Sage. Another one of those arbitrary things, but it seems reasonable to me that they are two of the most important CRMs in Gartners “Others” category.

Tweet Share

Quickly, though, before you take the survey, consider “Tweet Share” as another alternative. I’ve talked about Twitter in some previous posts, and tried to make the point that the value of Twitter lies in search. For example,

http://search.twitter.com/search.atom?q=”salesforce”=&rpp=50=&tude=:-)

returns the most recent 50 Tweets containing “salesforce.com” with positive “tude” (that is, containing a smiley face). The “atom” qualifier turns the results into an RSS feed that a good developer could do some analytics on. Compare the results you get for that search with what you get for this one:

http://search.twitter.com/search.atom?q=microsoft crm=&rpp=50=&tude=:-)

or for this one:

http://search.twitter.com/search.atom?q=crm online=&rpp=50=&tude=:-)

Now this is about as unscientific as you can get, but my observation from looking at those search results is that Microsoft has some work to do to win the “hearts and minds” of people who care about CRM enough to Tweet about it. To me it seems something like the AppExchange really drives the passion and energy in the SalesForce.com community – I’d love to see Microsoft do something like that!

The First Ever Trick Bag Market Leadership Survey 

[SURVEYS 1]

One of the first articles I posted on the re-launched Dynamics CRM Trick Bag was a bit of a rant about the Microsoft product Business Productivity Online Suite (BPOS, for short). This is Microsoft’s “cloud computing” suite of hosted Exchange, SharePoint and Live Meeting. I had a heck of a time getting it configured, and in the previous article I compared BPOS somewhat less than favorably with their other high-profile cloud offering, Dynamics CRM Online.

The day after I posted that article, my phone rang off the hook. I probably received ten calls from three different members of the Microsoft Online Services team. One of them ended up playing the quarterback role for me, and set up a call with the appropriate people from their side, with as it turned out two main goals:

1. Solve my problems and get my company up and running
2. Get my feedback about what they could be doing better to improve their service

I must say, I was quite impressed. I didn’t post the article thinking it would get a reaction like that, and I’m still not sure what kind of alerts they must have configured on Twitter to have reacted so quickly. But in any event, after a couple of calls and some changing of MX records and some making of the hosted email server “authoritative” for incoming email, we were up and running. We’ve been up now for a couple of months, it works great, I don’t get any untrapped spam anymore, and we’re a happy camper.
As far as the constructive feedback I offered them, I think it boiled down to:

• The distinction between the user site and the administrator site was confusing and should be cleaned up.
• They need better step-by-step instructions overall, and in particular for doing things like changing MX records & making the MS-hosted server authoritative for inbound email.

Based on my experience, I’d say that BPOS will be successful. The team is certainly listening to its customers and trying to fix their problems. I was amazed at how fast they responded to my venting, as well as with how carefully they listened to my input. They still have a little work to do in making it easier to get up and running, which I’ll try to summarize next.

BPOS and Dynamics CRM Online: User Experience Compared

I used the hosted version of Dynamics CRM (“CRM Online”) for about a year. (I used the free partner demo version, and kept our production CRM on the on-premise version – Dynamics CRM 4.0 Enterprise, to be exact.) As I mentioned in my previous article, the CRM Online user experience is better than BPOS, and the BPOS team would do well to take a page or two out of the CRM Online book. With CRM Online, you whip out your proverbial credit card, pay for however many seats you want, and you’re up and running immediately. In my opinion, any user who can use a web browser will be able to get CRM Online up and running; again, this is still not the case with BPOS, which I believe most organizations will not be able to get up and running without the assistance of a consulting shop or BPOS technical support. Not exactly the Gartner Magic Quadrant, but here’s one way to look at it:

One of the sweet spots for any hosted SaaS offering has got to be the small-medium business market. I suspect I’m not the only business proprietor who’s downsized in the past few years and simply can’t justify staff and infrastructure to maintain a bunch of servers in my shop. For me, there’s absolutely no strategic value in hosting my own Exchange Server, and very little in hosting my CRM server.

A big part of the costs of being on-premise are the costs of installing, configuring…getting up and running. In my opinion, the current version of Dynamics CRM Online effectively removes those costs, which will help push organizations to the online product.

The BPOS team has a great product and like I said above they seem very committed to improving the customer experience. But to really drive adoption, they need to change the “will require assistance” in the Up and Running column to “anybody can do this”; they have a high bar to shoot for, set by Dynamics CRM Online.

Once you’ve got the application definition file properly imported into your MOSS 2007 Shared Services Provider, using it within SharePoint is pretty easy. (again, this assumes you have some familiarity with SharePoint, know how to edit pages and use Web Parts! Apologies in advance if you don’t, but to keep the article to a reasonable length, I’ll assume that kind of knowledge). First I’ll go through a basic exercise of using two Business Data Web Parts to create a custom SharePoint page with a list of CRM Account records, and a related list of CRM Contact records. After that, I’ll show you how to create a custom “Action” so that a SharePoint user can select an Account and pop open a Google map window based on that Account record’s address information. I like this example since it’s actually a little easier to do that using this approach than it is using the pure-CRM approach where you need to write Jscript code for similar functionality.

Using the BDC Web Parts to Display Accounts and Related Contacts

If you work through this example you should be able to easily generalize this to other situations, but I’ll start with the “least common denominator” of Accounts and Contacts.

1. Create a new page within SharePoint. Make sure it’s a page layout that supports Web Parts!
2. On one of the Web Part zones, click Add a Web Part.
3. From the Add a Web Part dialog, scroll down until you see the Business Data Web Parts section, and select the Business Data List. You can actually add more than one web part at the same time, so to save a little of that here, I’ll add both the “List” and “Related List” Web Parts at the same time:

4. After you add them to your page you’ll see something like this:

 
5.  Click Open the tool pane to configure them, one at a time. The first thing you’ll need to do is identify which CRM entity you’re going to point each web part to – the first thing in the tool pane is the “Business Data Type Picker” you use for this. I usually browse out to see the entities that are exposed and you can see familiar CRM entities in the following figures as I go through this process:

6. First I’ll select Account, then Contact. Once I’ve got them selected and on the page, notice there’s an Edit view button available. Use this to deselect some of the fields (attributes) so that you don’t have to scroll all the way across the SharePoint page. I won’t go through all the details of that, but here’s what it looks like after I’ve deselected a lot of the fields, and customized the properties to only display ten records at a time:

7. Remember I said I wanted to select an Account record, and then be able to see all of the related Contact records. The web parts do most of the work for us, since they are defined as “Connected” web parts, and I can use the web part UI to pass a selected item from the Account List Web Part to the Contact Related List Web Part, as this figure shows:

8. Finally, what does it look like to a user? After locking those configurations in and taking our page out of edit mode, it might look something like this:

You can see I’ve got an Account record selected, and the three Contacts associated with that account are displayed in the Contact Related List web part. (I’d probably drop the ID columns before declaring this to be “in production”.) Notice the pull-down Edit menu in SharePoint, exposing commands like Create Account in MSCRM, and Edit Account in MSCRM. Those are so-called Actions. In the next section I’ll show you a cool and promising extension of the basic functionality: creating custom Actions. The View Map command you can see above is one of these and as I said…we’ll look at that next!

Creating Custom Actions

In the previous figure, everything except “View Map” is an out of the box Action pre-defined within the BDC application definition. One of the coolest things about the BDC is that you can define your own custom actions, and for actions that involve navigating to a URL and passing CRM data into the URL, you can do it entirely within the SharePoint UI, once again with no code required.

To illustrate this, I’ll go back to my Shared Services Provider, and navigate into the BDC application definition for my Account entity. I’ll navigate to the View Entity page for Account, and scrolling all the way to the bottom I’ll see something like this:

 
Look at that maps.google.com URL. If all you do is open a browser and navigate to google maps and enter an address in the Google search box, you get the same results as if you directly enter an address like this in the browser address box:
http://maps.google.com/?q=1415 west 22nd street oak brook il

This means that the google maps functionality is easy to construct a URL for, since it’s pretty forgiving, and doesn’t care much about spaces or quotes or things like that. So all you need to do to construct the custom Action so that users can do this without having to worry about typing anything is click the Add Action button, and specify the parameters you want to pass in to the URL, and how they correspond to Dynamics CRM fields:

In this article (part 1), I’ll show you how to set up the CRM 4.0 Enterprise Search Accelerator.

In part 2, I’ll show you how to use the Business Data Web Parts to expose CRM data to SharePoint users, and how to create custom Actions for CRM records.

In part 3, I’ll show you how to configure SharePoint search to allow users to search CRM accounts, contacts and other entities directly from within SharePoint.

Background

The Business Data Catalog (BDC) is a very nice piece of functionality that ships as part of MOSS 2007. What it lets you do is to import an “application definition” into a MOSS Shared Services Provider. This application definition is in the form of a complicated XML file that points to a SQL data source and defines all of the entities it contains in a way that lets SharePoint understand them and expose them through search and web parts.

If you have some experience with SharePoint and the BDC you will find this an excellent way to surface highly formatted CRM 4.0 data through the more ad-hoc SharePoint UI. If you haven’t worked with SharePoint much it might take a little getting up to speed, but if you need the functionality it’s worth it!

The BDC has been a great tool since it was first released, and once you’ve got the application definition (XML) file defined properly and imported into SharePoint, it’s a nice no-code way for a power-user to integrate SQL and “line of business” data into the SharePoint experience. However…that “once you’ve got the application definition (XML) file defined properly and imported into SharePoint” is a big caveat! Creating those things is well beyond the skills of most of the power-users who end up using the BDC in SharePoint, and since there really weren’t any application definitions or tools to create them until fairly recently, the BDC hasn’t gotten as much use as it might have.

What does this have to do with the Enterprise Search Accelerator? Well, everything, since all it is is a reference BDC application definition file that you can import into SharePoint and expose standard out of the box Dynamics CRM 4.0 entities! Since many organizations get a lot of mileage out of the standard out of the box CRM entities, to have a BDC definition that creates all of those entities in SharePoint and allows you to expose them to your SharePoint users is a huge time saver!

The Search Accelerator was released in January 2009, and is one of the eight currently available Accelerators, all of which you can see here: http://crmaccelerators.codeplex.com/

Setting up the Enterprise Search Accelerator

There’s a little bit of setup involved, but it’s not too difficult. It definitely helps if you’ve had at least a little experience working with SharePoint search. Logically, I break this section out into two main sub-sections. First, you need to import and configure the so-called “Application Definition”; this is what allows SharePoint to understand and expose your CRM database. Then, if you want SharePoint users to be able to search CRM data the same way they would search SharePoint content, you need to configure SharePoint search. In order to keep this article reasonably short, I’ll only discuss the first of those two setup requirements here, and I’ll save Search configuration for a separate article. 

The fact that this accelerator is referred to as “Enterprise Search” confuses the point a little, at least for me. What it really does is to give you an application definition file so you can access a Dynamics CRM organization using the BDC functionality. So all of the search functionality is a come-along with the BDC, and the search functionality is optional at that.  The documentation that comes with the download is very good and quite complete, but it’s almost too complete, in the sense that for a lot of people many of the steps will be unnecessary. For example, on the VPC I installed it on, I only had to perform the 5^th step of the 5-step setup process, since my VPC already had all the SharePoint-specific stuff done. The instructions are written for the out of the box public VPC image I referred to above, so just keep in mind that for your SharePoint environment, it may be quite different (and possibly a lot quicker!)

Importing and Configuring the Application Definition

As I mentioned above, creating these application definitions from scratch is tricky at best. For example, the application definition file included in the Enterprise Search Accelerator consists of 15,000+ lines of dense XML code!  So I was glad to have the heavy lifting already done for me.

There were really only two changes I needed to make to the xml file that defines the BDC for the Enterprise Search Accelerator (file name: MSA_MSCRM_BDC_V1.0.xml, included in the “source code” folder)

Updating the SQL Database the BDC Points to

First, I had to change the name of the SQL database within the CRM organization that it points to. The file that ships with the accelerator is set up for the public VPC for Dynamics CRM (you can download it from here:  http://www.microsoft.com/downloads/details.aspx?FamilyID=DD939ED9-87A5-4C13-B212-A922CC02B469&displaylang=en ). I was using a different VPC image with different CRM organizations, so I had to make one change. Towards the top of the file, there’s a line that specifies the “RdbConnection Initial Catalog”, and I needed to change the value to “AdventureWorksCycle_MSCRM”. This is the name of the SQL Server database for the organization I wanted to point to. As far as I could tell this wasn’t documented anywhere in the Accelerator, so I guessed and got lucky. Here’s what that part of the file looks like:

Updating URLs for Navigating to Dynamics CRM Records

The only other change I needed to make was to fix the CRM URLs within the BDC file. As you will see in Part 2, the BDC lets you define “Actions” that can be performed by a user when (for example) selecting a CRM record exposed through SharePoint. Many of these Actions use the “URL-Addressable Forms” capability of CRM. Since these are defined within the BDC application definition file for a specific CRM deployment, you will generally need to update these URLs.

You can import the BDC successfully without doing this, but when you try to navigate to any of the Dynamics CRM records exposed through SharePoint, you’ll get a 404 URL not found error, essentially. You can see the change I made in the next figure. This actually is easy, since you can do a global find and replace. In my scenario I needed to replace the CRM URLs on the VPC the file was written for – http://moss:5555/microsoftcrm — with the ones on my VPC – http://crm. There were about 25 references to that URL, and after I changed them all, I was good to go. Here’s an example of making these changes:

 
Importing the Application Definition

Once the XML file is all configured, importing it is easy:
1. Navigate to the Central Administration web site for your SharePoint (remember: MOSS 2007!) server.
2. Click underneath “Shared Services Administration”, on the Shared Service Provider for your SharePoint server.
3. In the Business Data Catalog section, click “Import application definition”. You will see something like the following figure:

 
4. Browse out to the XML file that contains the definition of the BDC (MSA_MSCRM_BDC_V1.0.xml), and then click “Import”. After you do this it will take a while and you’ll see all the lines of the file getting counted through as the import whirs along.
5. After it’s done, you will have a sweet new BDC application imported; with any luck you’ll see something like the following:

 
6. You can click on the name of the application to see all of the entities it has now exposed through SharePoint. If you’re familiar with Dynamics CRM you’ll be happy to see something like this:

 
7. You can imagine that if you click on Account or Contact from this page, you will see all of the attributes that the BDC has defined for that entity. But at this point, we’re ready to expose our CRM data to our SharePoint users, which is the topic for Part 2 of this three-part series.

Background: Internet Marketing and Lead Capture

One of the most important functions required to integrate Internet marketing into your overall CRM marketing efforts is “Internet lead capture”: the ability to drive traffic to a web page with a form on it, have a visitor fill in the form, and pop the submitted information directly into your CRM database. Up until recently, if you wanted this kind of functionaliy in Dynamics CRM you had to write server-based .NET code. The code itself isn’t terrible and plenty of people figured out how to do it, but it’s a hassle, and it’s beyond the technical reach of a lot of the sales and marketing people who need the functionality.

Recently some easier approaches have begun to emerge. I’ve written a couple of articles about one of them — the Internet Marketing functionality available now in Dynamics CRM Online — and I’ll include links to those at the end of this article. The obvious problem with this is that it’s only available for CRM Online, the “cloud” version of Dynamics CRM that Microsoft hosts from this site: http://crm.dynamics.com/ I’m a big booster of CRM Online: it’s solid, reasonably priced, and brain-dead simple to get up and running. But…most organizations are still using the on-premise edition, and the integrated Internet Marketing functions aren’t available in the on-premise edition. (Yet)

What does Web 2 CRM do?

A couple of days ago I got this flyer in the mail:

It was apparently an effective pitch: the first chance I got I navigated to www.CRMInnovation.com/web2crm to see what I could find out about this product. It’s described there as a code-free way of creating lead-capture pages that will pop data right into my CRM, so I followed the link to http://web2crm.crminnovation.com/ where I signed up for my free 7-day trial. Seven days isn’t much time so I had to get busy! Here’s how it works:

How does it work?

First you create an account and credentials for yourself, much as you would for any other service, but the big difference here is that you point to your Dynamics CRM organization as part of the process. The Web 2 CRM product is hosted by CRM Innovation, so when you ultimately create the lead capture form it needs to point to your CRM organization, and it needs admin credentials so that the Web 2 CRM code can communicate via web services with your CRM database (I assume that’s how they do it — I haven’t delved under the covers quite yet).

Figure 1: Logging in with user account and CRM organization

 In the “Configure Logins” tab I’d already pointed my account to my on-premise CRM, supplied by admin credentials and so forth. After I sign in, you can see it starts to get interesting:

Figure 2: Select the Entity to Add a Record for

 Notice that I’m asked to select an entity from a pull-down list. All of the entities in the CRM organization I’m pointing to will show up here, including custom ones. The one I select will be the entity the submitted forms will create records for!

So while I could create a Contact or Lead record, I started my experimenting with this application by creating a custom entity, Internet Lead. You can see it in the next screen shot:

Figure 3: Even Works with Custom Entities

Next, you select the entity and click the Create Form button. You will something like Figure 4, which is really the heart of the Web 2 CRM “development” experience. It shows you the existing form for the CRM entity you selected, and you can drag and drop Dynamics CRM form fields onto the middle area, which is the development version of the web capture form you’re building! After about 5 minutes with this tool I got pretty comfortable with it. Figure 4 shows a form in progress, with some of the fields selected from the CRM form and exposed on the Web 2 CRM form. You use the “Form Header” text box to give it a title. There are a few different styles and looks you can get with the various options in the Form Settings and Published Page Settings areas, but I’ll stick to the basics for now.

Create a Default Hosted Form, or Copy a Code Snippet into a Custom Page you Host 

Once you get to this point, just save the form (Save Form…), and give it a name. Then you can Publish it, and sure enough, it actually creates a form (with about as cryptic a URL as you’d expect), and your Internet Lead capture form is done! Here’s what one looks like — notice that the “enable captcha” checkbox is selected above, and you see the little math pop quiz that spam bots aren’t so good at as it displays on the form:

 

Now of course comes the harder part of driving traffic to this form and getting people to fill it in, but the good news, if they do, sure enough you get a brand new record in your designated CRM entity! It really works quite well, and as advertised, no code required.

If you look back at the screenshot of the design environment, notice there’s a “Carry Code” button. If you click that, you get a pop-up window with some script code you can copy to the clipboard, and then paste into the HTML of one of your pages. This is how you can get past the plain vanilla appearance of the default form you see in the previous figure. I was pleasantly surprised how well even this last part worked. It took me about 5 minutes to create a page within my WordPress blog, and I copied and pasted the code using that  Carry Code button, and even though it’s not fancy, you can see the difference between this form and Figure 6:

Summary, Comparison to Dynamics CRM Online Built-in Lead Capture

I like this tool and I recommend it. It costs $495 and there’s a 7-day free trial as I mentioned. If your organization needs this functionality, it would almost certainly cost you more than $495 worth of of development’ time to implement the functionality.

In Dynamics CRM Online (the cloud version of Dynamics CRM), there is an “out of the box” version of a similar kind of functionality. It’s always been somewhat limited compared to the Web2CRM implementation, but I had hopes that some of the limitations would be addressed in the November 2009 Service Update. In general they were not, so unless the $495 is a deal-killer I still recommend the Web2CRM product.

Here are the main criteria I use to compare Web2CRM with the built-in Microsoft “Lead Capture Form” functionality:

• Web2CRM lets you push web form data into any CRM entity; the Microsoft tool only pushes into the Lead entity. This is a significant limitation of the Microsoft approach. In practice, what it means is you have to over-burden the Lead entity with all kinds of fields it shouldn’t have. For example, with Web2CRM I can create a custom entity called “Survey Results” and use it to capture survey information submitted from a web form. With the Microsoft tool I’d have to add more attributes to the Lead entity. Once you start to realize all the potential places you can use this “web 2 crm” functionality…well, your Lead entity gets pretty messy!
• Web2CRM pushes data directly into the entity in question; the Microsoft tool uses a placeholder entity and requires you to manually import records into Leads. As I showed above, Web2CRM implements a captcha scheme to filter out form-spam, but once the form is filled in the data go directly into Dynamics CRM. The Microsoft approach forces a user to manually import data from the “Internet Lead” placeholder. Since the Internet Lead entity isn’t really an entity (e.g., no workflows can be written against it)  the Microsoft approach means you really can’t have an auto-responder workflow.
• The out of the box forms produced by the Microsoft tool are cooler looking than the ones produced by Web2CRM.

In my opinion, this last point is the only real advantage of the Microsoft approach over Web2CRM. For me, it’s not enough to offset the disadvantages, so for most of the web forms I create (and for all of the ones requiring complex forms and custom entities) I use Web2CRM.