Archive for August, 2009

CRM Mobility Solutions Survey Results

The polls are closed and the votes tabulated in the first annual “Highly Unscientific Dynamics CRM Mobility Solutions” survey, and I’ll summarize them here. Depending on the question, we got between 15 and 18 respondents. So while I’d hesitate before making investment decisions based on these results, the responses were certainly interesting, and appeared plausible. (e.g., a lot more people indicated they were considering deploying a mobile solution than had already deployed one).

A little background: the Dynamics CRM User Group held consecutive meetings (July and August) on the topic of “Dynamics CRM Mobility Solutions”.

If you took the survey, I apologize for the fact that you couldn’t see the survey results after taking it. I used a WordPress Plugin to expose the survey from my blog…and only after I’d posted it did I realize that only an admin can see the survey results! (If you know of a sweet survey Plugin I can use that solves that problem, please let me know!)

Herewith, the Survey Results

 

Question 1: is your CRM accessible on a mobile device?

I was surprised by the high percentage of “Yes” responses on this first question. My casual observation is that it’s lower than that. On the other hand, a high percentage of our respondents were probably consultants, IT folks and more technical types, so that could account for the higher-than-expected percentage of Yeses.

Question 2: Are you considering deploying a mobile solution?

This isn’t surprising at all. People who took the time to take the survey and attend the user group sessions would be likely to be considering deploying!

 

Question 3: Which mobile platforms are the most important?

 

Question 4: Which of these solutions have you already deployed?

 

Question 5: Which of these solutions are you considering?

The responses to the last two questions surprised me a little bit, but again, I take these numbers with a grain of salt. Apparently Erik van Hoof’s keen presentation at the July meeting had some positive impact for CWR Mobility!

Comments (3)

Clone Records using Entity Relationships

Different Approaches to “Record Cloning”

In another article I described how you can use a simple workflow to implement a “record cloning” function in Dynamics CRM. There’s an alternative approach which takes advantage of one of the three new kinds of entity relationships you can create in the Dynamics CRM 4.0 version: namely, the ability to create “self-referential” relationships. In plain(er) English, this lets you create 1:N or parent-child relationships between records of the same type.

For example, you might have a case record with other related case records. Or a parent opportunity record with several associated “child” records. True to the dictum that if all you have is a hammer everything looks like a nail, once you know how to clone records you’ll be surprised at how many different scenarios you can use it for.

How this Approach Works

For the entity-relationship approach, you need a security role like System Administrator, so you can customize the entity you need to clone and publish those customizations. That’s one of the most important differences, by the way, between this and the workflow approach. (More on that later). Assuming you can do that, this is essentially a two-step process (using the Opportunity entity to illustrate):

  1. Customize the Opportunity entity, and create a new 1:N relationship from Opportunity to Opportunity. Give it a good name and accept most of the default options.
  2. Once you’ve got the relationship created, you can create “mapped fields” for the fields you want auto-populated from the parent record to each new child record.

After you publish your customizations, that’s pretty much it. I’ll write this up in more detail shortly, but in the meantime, here’s a video I uploaded to my YouTube channel that walks through it step by step:

Leave a Comment

Clone CRM Records using Workflows

Why Clone Records?

Sometimes, it can be time-consuming to create Dynamics CRM records. And in most cases, this isn’t a bad thing: it takes time to enter good data, and the more care taken when entering them, the more useful your CRM will be!

But sometimes, data entry can be tedious and repetitive with little payback. Suppose you need to enter multiple records, one after another, each of which is only slightly different from all the others. This will depend on the specifics of your business, but I personally see it a lot when entering opportunity records. For example, I recently need to enter seven relatively complex opportunity records, each of which represented a specific (billable) part of a large project. There were about 10 fields that would contain the same value for all these records, and 2 that would be different.

What I needed to do here is to “clone” a record: create a new record based on an existing one, and copy some or all of the field values. There’s no out of the box way to do this in Dynamics CRM 4.0, but there are some easy customizations you can use to do it. Here are the two I use the most, each of which should be in your bag of Dynamics CRM tricks:

  1. You can create a one-to-many relationship from an entity to itself. (This might sound a little existential, but it’s not. It’s actually self-referential. Sorry, I couldn’t resist.) I discussed and demonstrated that approach in this article.

    This “self-referential” approach creates a parent-child relationship between the record you clone and all the records you create from it, and you “map” the fields whose values you want to copy. In certain situations this might be what you want, but not always. In the opportunity scenario I sketched out above I didn’t want it: the opportunity record I started with wasn’t a parent record to any of the others, it just happened to be the first one I entered.

  2. For situations like the one I’m describing here, you can use a simple manual workflow to create all the similar records you need. It can be a one-action workflow that simply creates a record of the same entity type, and populates the field values you want copied with their values on the record the workflow was run against.

Cloning Records with the Workflow Approach

Here’s the step-by-step process I used to create the “Clone Opportunity” workflow:

  1. Create a new blank workflow, selecting Opportunity in the Entity list:

     

  2. This is going to be a manual workflow, so uncheck the “Record is created” default, and check “On demand”.

     

  3. I usually collapse the Workflow Properties area, by clicking the Hide/Show toggle switch. Anyway, pull down the Add Step menu and select the Create Record action. After you do that, click the Set Properties button you will see.

     

  4. Then you just need to fill in the fields on the record the workflow will create…with the corresponding values from the existing record. It takes a little practice to get used Dynamic Values in the workflow design environment. In the next figure I’ve selected the “Topic” field in the field drop-down underneath the entity drop-down in the Look for section. Then click Add, then click OK. (Don’t worry, you get used to it after a bit!)

     

  5. Then just fill out any of the other fields you want values copied for. It’s easy since they’ve all got the same name! In the following figure I show all of the fields on an un-customized opportunity form filled in except for the “Est. Revenue” and “Description” fields. Again, the specifics of your business will determine which of the fields you want to fill in from the original opportunity record.

     

  6. Click Save and Close. Then you can publish the workflow and you’re ready to go.

 

Once it’s published, it’s easy to use. Just create a record you want to copy, and since the workflow was published as an “On demand” workflow, a “Run Workflow” button will now show up on the form toolbar, like this:

You can just clone the same record by running the workflow multiple times, or modifying a cloned record and then cloning it…experiment and see which way is quicker for you. Here are a few records I cloned in this way, just to show an example of what it might look like when you’re done.

The example I showed here was a simple one, but even so, having a “clone record” workflow I can use will save me some time. In the real world, organizations tend to have highly customized opportunity entities with a lot more fields that need to be filled in. So if you ever need to create similar opportunities out there in the real world, this trick might save you some time!

I wrote a book on Dynamics CRM workflows, by the way, and it contains tons of examples like this one and other useful workflows. You can purchase the book on Lulu.com or on Amazon, and if you do, you can also get a (free) subscription to the online version of the book, where you can download the workflows themselves, customizations, and related content.

Here’s a link you can visit to find out more about my book and purchase it:
Support independent publishing: Buy this book on Lulu.></a></p>
				</div>
			
				<p class= Comments (4)

CRM Mobility Solutions – August DCRMUG Meeting

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.

Comments (1)

CRM Mobility Solutions Survey

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]

Leave a Comment

Lookups Against Closed Records

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:

Comments (3)

Record Ownership and Assignment

“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!

Leave a Comment

Self-Referential Relationships and Closed Records

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

Comments (3)

Gartner Says Dynamics is Fastest Growing CRM

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:

 revenue

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.

 

 revenuegrowth

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.

 

 marketsharegrowth

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.

Comments (1)

Thar’s Organizational Gold in Them Thar Outlooks

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:

Leave a Comment