Herewith, the Survey Results

Introduction, “Mobile CRM” Backgrounder

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.

Keeping to the theme of the Dynamics CRM User Group’s Mobility Solutions So-Hot Summer series, I thought a little survey might be interesting.

And don’t forget to register for the August meeting of the Dynamics CRM User Group, featuring Microsoft and TenDigits presenting on their mobile solutions.

[SURVEYS 2]

In a recent post I included a thread between Bob Haverty and me regarding a question he’d emailed me and to which I didn’t have a good answer. I tweeted about it, included a link to the post and encouraged readers to post comments if they had any ideas about or answers to Bob’s question. The next day, Jukka Niiranen
was generous enough to post a suggestion and a link to an article by Jim Wang that solved Bob’s problem. Thanks Jukka!

Here’s the article by Jim Wang: http://jianwang.blogspot.com/2009/04/show-both-active-and-inactive-records.html

Here’s the URL of Jukka’s blog: http://niiranen.eu/crm/

This is actually a more general point than I thought at first. (Bob, next time you email me a question I’ll read it more carefully!) What it really has to do with is whether closed records show up in an entity’s Lookup view. By default they don’t, even though there’s no real reason they shouldn’t. You can see an example of this if you have an activity record – task, email, … take your pick – attached to an opportunity. If you close out the opportunity the activity record is still intact, and you can still see the opportunity record in the Regarding (lookup) field on the activity form. You can even click the link to the (now closed) opportunity record and navigate to its form, and verify that the record is closed. But I you tried to select the closed opportunity record from the lookup view, you can’t – closed records aren’t exposed there by default!

From a business standpoint there might be plenty of times when it’s appropriate to attach something like an email, phone call or a task to a closed record. What if you were sending an email to a colleague and wanted to make it regarding a previous opportunity that happened to be closed? Or how about if you were making a followup phone call regarding a case that had been resolved? By default, you can’t do any of these things, because closed records don’t show up in the lookup view.

To allow the attaching of an activity record to any closed record, all you have to do is customize the specific activity type (email, phone call, task, etc.), and add this code to the form load event:

crmForm.all.regardingobjectid.lookupclass = “alllookups”;

Here’s what the load event will look like if that’s all you have in there:

What does that “regardingobjectid” refer to? That’s simply the attribute name of the standard “Regarding” lookup field you see on every activity form in Dynamics CRM. You can see it here it is on the standard E-Mail form:

Since there’s only one “regardingobjectid” field, this will work no matter what kind of record type you want to attach the activity to! And remember, this means that after publishing these customizations, you will see a lot more records in your lookups than you did before…because now you see both active and inactive records! So, you might want to add the Status value to the Lookup views for important records. With the default settings that isn’t necessary since you won’t see any inactive records. But with the approach described here you’ll see all records and you might want to give your users the ability to distinguish between active and inactive ones. Here’s what my Regarding lookup view looks like now if I select the Opportunity entity, after I added Status to the Lookup view:

“Out of the Box” Behavior when Records are Reassigned

By default, Dynamics CRM does a lot more than people generally realize when records are reassigned. For example, if you reassign an account record from one CRM user A to user B, the default behavior is for all child records of the reassigned account to also be reassigned to user B. This might seem reasonable at first, but when you realize it applies to every one of the following record types regardless of its status, it can seem a little alarming:

Suppose you use some combination of the sales process records (Opportunity->Quote->Order->Invoice) for historical sales reporting. If you do, and you’re relying on Dynamics CRM’s “out of the box” relationship behavior, reassigning an account record will definitely impact your historical sales reporting, essentially “reassigning” everything from won opportunity records to paid invoices to whoever the account was reassigned to!

Fortunately, there’s a relatively easy fix for this. The fix is easy enough…but in my experience it’s often made only after the problem is discovered. I’ve had plenty of clients who didn’t realize this for some time, and wondered why their historical sales reports were always changing. (These were clients I started working with after they’d already implemented and been working with CRM for a while, by the way!)

The Problem with Reassigning Records

First of all, what do we mean by “reassigning” records? In CRM-speak, I’m talking about changing the value of the “Owner” field (a so-called lookup attribute). Here’s what it looks like on a standard account form:

Selecting a different value for the “Owner” field in this case would reassign the account to the newly selected CRM user. Along with a lot of other records, which is the potential problem. Assuming you’ve got sufficient security privileges, you can see the problem by following these steps:

1. Click Settings, Customization, Customize Entities.
2. Double-click Account from the list and the Account entity’s customization form will open.
3. Click 1:N Relationships in the Details area, and you will see something like this:

   

    

   This looks alarmingly confusing the first time you see it, and in my case, it wasn’t just the first time! This is the complete list of all of the 1:N relationships the Account entity has with other Dynamics CRM entities, and one of the great things about Dynamics CRM is how you can customize these relationships.

    

4. I think the best way to develop some intuition is to sort this list by the “Type of Behavior” column – just click on the column heading, and you’ll see something like this:

   

    

   Notice the “Type of Behavior” for the relationships that appear first in this sort is “Parental”. The reason I like this view is that these happen to be the out of the box relationships that make all of that reassigning happen, and they also happen to be the only relationships you can customize. (If you scroll down past these you’ll see System relationships, none of which you can change.)

    

The Fix

Now that we know where the problem lies, how do we fix it? To keep this article reasonably short, I’ll go through an example for the 1:N relationship from Account to Invoice. The steps will be identical for any other relationship, although business requirements might dictate different specific settings you’d make.

1. Double-click the line with “Invoice” as the Related Entity. You’ll see the Relationship dialog for the Account to Invoice 1:N relationship:

   

    

2. What you need to do here is change the default “Parental” relationship to “Configurable Cascading”. Pull down the “Type of Behavior” menu — the screen-shot shows me in the process of making the change. After making the change the dialog changes and the fields in the Relationship Behavior section are now selectable, as you can see here:

    

   

    

   Now you can see why the out of the box reassignment is so frisky: “Cascade All” means in this case that when the parent record (Account) is assigned (or re-assigned), the change cascades down to all child records (in this case, Invoice records attached to the Account). Depending on your business requirements, Cascade Active or Cascade None might be appropriate. I use Cascade Active for my organization, which essentially means that the new Owner of the account record will cascade down only to invoice records with a status of “active” – that is, completed or paid invoices will not get reassigned, which was the problem I was trying to fix.

3. Select Cascade Active, then click Save and Close to close the Relationship Behavior dialog.
4. Then click Save and Close again to close the customization form.
5. Finally, publish the changes by selecting Account in the entity list and clicking Publish.

That’s pretty much it. You’ll need to go through the same process for any of the other 1:N relationships you want to change; in my experience the most important ones to start with are probably the sales process entities I mentioned above.

Also, the same issues apply to custom entities you create: they can have 1:N or N:1 relationships to out of the box entities like Account, and while the default settings for those relationships may be fine…they may not be fine too. When it comes to custom entities you have more options. I’ll discuss those in a separate article, but in the meantime here’s a quick summary (if you need to do this you’ll see what I mean):

• A Parental relationship is the most restrictive. As you saw here, we started with Parental from Account to Invoice, which meant that every change to the parent record cascades down to the child records.
• Referential is the least restrictive, and nothing cascades down.
• Configurable Cascading is the most flexible…and the one you have to think about the most!

I recently received an interesting email from Bob Haverty, a former student in a CRM class I’d taught a while back. It’s a specific issue having to do with parent-child relationships between quote records, and what happens when the parent record is closed. I’m initially stumped by this one, so I thought I’d post it as an interesting and fun challenge for TrickBag readers. Bob summarizes the issue pretty well in his first email, but I included the rest of the thread in case you want all the detail. If you have input, please comment on the article – thanks in advance!

Here’s the thread, starting with Bob’s first email:

Hi Richard,

I was a student of yours on a week long web class something around 6 to 8 months ago. I have come across a question in my current environment that I have not been able to locate an answer to and I hoping you can help.

As a matter of business process, I have a need to be able to create a self-referential relationship on my quote entity, allowing me to link a quote to any other quote in the system.  The reason is that often times the quote that is presented to the customer is not the one that gets ordered.  After presenting the quote to the customer, it may further be modified, triggering revisions, but we would like to link back to the quote that was originally presented to the customer.  The issue is that the quote that was presented is now closed. The lookup field on my quote is not allowing me to see closed quotes (earlier revisions).  Do you know of anyway for me to create this type of relationship to see closed quotes from another quote via a lookup?

Thanks in advance for any advice.

Bob Haverty

Corporate Technologies

I replied:

…rather than creating a custom self-referential relationship like you’ve done, why not just use the built-in quote revision process? (activate a quote to present it to customer and lock it down; if revisions are necessary, revise the quote which increments the revision id but keeps it tied to the same underlying quote, etc., etc.) Is there something about that process that doesn’t fit your requirements? …

Richard

Bob responded:

We certainly use the revision process while we are going through the sales process with the customer as the sales rep is refining the quote in either pricing or content, however we are presented with two different scenarios where the revision process breaks down for us quickly.

The first scenario, which is the easier one (an arguably the easier issue to solve) is that the sales rep presents a quote to a customer, the customer orders the quote, but the quote that needs to get booked through order actually ends up being very different because the sales rep hid discounts or part numbers from the customer.  In this case we would need the ability to go back to the customer quote to be sure that regardless of what was ordered, we invoice them according to the customer quote.  That’s why it is critical to tie them together.  We could probably do this through revisions.

The second scenario is a case where a customer orders product from us, as well as maintenance on that product.  The sales rep presents the quote to the customer, they approve it and issue a PO.  That quote is activated(locked), but we then revise the quote at time of order because we actually split the quote into two pieces (one product and one maintenance piece).  We do this with a “copy quote” function.  At this point we now have:

Quote A – which is the original quote that the customer ordered with all parts on it.  This quote is closed because we have……..

Quote A1 – which is the revision of quote A.  This has just the product pieces on it.  Maintenance items have been removed.

Quote B – which is a copy of A1, except it has the product items removed and left with only the maintenance items.

Both Quotes A1 and B will become orders after following their respective workflows through different depts., but we would like to be able to link them back to Quote A so we always have a reference what the customer actually issues a PO against.

I know it is confusing as all get out.  Took me a while to get my head around it.  Let me know if you have further questions.

Thanks, Bob

In its most recent CRM Software Market Share Analysis report, measuring year over year growth from 2007 to 2008, Gartner found that Microsoft Dynamics CRM was the fastest growing product in the CRM space. Here’s a link to the summary of the study: http://www.gartner.com/it/page.jsp?id=1074615

Since a picture’s worth 1,000 words, here’s a three-thousand word article summarizing the Gartner study:

Dynamics CRM revenue was up to $581M in 2008. (all numbers in millions of US dollars). SAP is still the market leader in terms of revenue, but its revenue actually fell slightly, from $2.07B to $2.05B.

Dynamics CRM led the way in terms of revenue growth, with a whopping 75% growth rate from 2007 to 2008. I thought Dynamics CRM had lots of momentum in the marketplace, but that 75% growth rate surprised me! Salesforce.com did pretty well also.

Microsoft’s fast revenue growth means it’s taking more market share: from 4.1% in 2007 to 6.4% in 2008. Salesforce.com grew also (from 8.3 to 10.6%), but not as fast as Microsoft (a little less than 30% growth in share). At this rate, Microsoft will pass Salesforce.com in the next year, maybe two.

How and Why to Promote your Outlook Contacts to Dynamics CRM

This is the second in a series of recorded sessions on realizing business value from the Dynamics CRM Outlook client. Here I focus on how to promote standalone Outlook contact records to Dynamics CRM, and how to work with the subsequently synchronized records. 

If you’ve got Outlook users, you’ve got contact records locked away on desktops that should be shared and cared for in your CRM. The Outlook client gives you a great way to get this done: