May 6, 2012 – Today’s episode wraps up the remarkable five-year run of the best podcast ever, The History of Rome. I discovered Mike Duncan’s podcast in early 2008; Episode 1 (In the Beginning) was published July 2007. So, unlike Buffy the Vampire Slayer, Cowboy Bebop, The Wire, and other masterpieces of popular culture, I came to this one early on. Of the 250 or so Sundays since kicking things off, Duncan clicked Publish on 179 of them. For me and lots of other THoR fans, that always took the sting out of the end of a weekend.

I don’t believe Duncan considers himself a professional historian, and that’s one of the reasons this podcast so much fun. I’m no authority on Roman history, but my guess is the podcast doesn’t cover much ground academic historians would consider new. But if you’re like I was a few years ago – like history but don’t know much about Rome – you should start from the beginning and listen to every one of these episodes. What will you learn? Well, here are a few nuggets from my top x favorite episodes:

• In Episode 1 we learn who Queen Dido was, and the real reason Rome eventually got into it with Carthage.
• In Episode 2 (Youthful Indiscrations), we learn what the Rape of the Sabine Women was all about. (I’d always wondered what that was, and now I know!)
• Just to pick two gems from the Ten episodes devoted to the three Punic Wars (five alone to The War with Hannibal), we learn where the term Fabian Strategy comes from, and how the charismatic, long-haired rock-star/general Scipio Africanus sowed the seeds of the fall of the republic.
• 29-34 are the “rise of the populists” episodes, introducing, in order, the brothers Gracchus (Tiberius and Gaius), then Marius, then Sulla, then Marius and Sulla.
• Next we come to Crassus and Pompey…and then of course to Julius Caesar, who gets Episodes 39-46. Caesar’s got a bad rap (killing off the republic & all), but he gets my vote for the Roman I’d most want to drink beers with. Episode 39 (The Young Julius Caesar Chronicles) is one of my personal favorites, and if you ever wondered where O. Henry got the idea for The Ransom of Red Chief, listen to this episode now!
• Then we move on to the emperors. I’m going to be very selective here (since this is already getting too long): Episode 61 (What, me Claudius?) is also on my top-three list. In Episode 66 (666) we learn why Nero could not possibly have fiddled while Rome burned; in Episode 70 (Galba and Otho) I learned that Galba is among the emperors I’d least like to drink beers with; Episodes 79-95 (98 to 180 AD or so) cover the golden age of the empire, from Trajan to Marcus Aurelius. In episode 95 (The Beginning of the End) Commodus (Joaquin Phoenix in the movie) starts to screw everything up, and leads the way into the confusing and completely messed up 200s AD, during which the empire split into Three Empires (episode 113, 260 AD), and might have gone down the tubes entirely if it weren’t for episode 116 (Here Come the Illyrians).
• Another episode on my top-three list: 119 (Restitutor Orbis, 274 AD). The big takeaway: when it comes to peak value (as opposed to career value), Aurelian is the Sandy Koufax of Roman emperors.
• Duncan also has an apparently solid understanding of economics. His explanation of inflation, by way of analogy with the famous Donald Duck episode where Huey, Dewey and Louie get hold of the Duplicator Ray, is not to be missed. It’s also not to be found (by me, this weekend)…but I know it’s there somewhere in one of those 179 episodes.

About halfway through the podcast, Duncan was offered a sponsorship from www.Audible.com and started reading a short pitch at the start of most episodes. I was glad when he did that; anybody who creates content as good as The History of Rome deserves to be rewarded for it. The pitch includes a URL — http://www.audible.com/historyofrome — where you can sign up for a free trial, and if you ever want Audible, I encourage you to use that link to do so. He also started doing History of Rome tours: http://www.historyofrometour.com/. My hope is that the tours have been so lucrative that he keeps doing them until I can work my schedule around one.

What else might he spin off from THoR? Well, if he did a book, I’d buy it for sure. Two of the best reasons to do a book:

1. He could include some nice maps. There are some on the podcast site, but I think book-quality maps would add a ton of value.
2. I could look up “Huey, Dewey and Louie” in the index and find that inflation episode.

I’ve already completed one spinoff with absolutely no commercial value, but it was fun and didn’t take too much time. (see below)

Vale, THoR

The 1,229 year history comes in at just about 7 years per episode. With an average episode length of about 25 minutes, Duncan covered about three months of Roman history per podcast minute. Just right.

Thanks Mike. Sunday nights just won’t be the same.

xRM History of Rome Application

Want a list of Roman emperors in a spreadsheet? Here you go.

Spreadsheets are OK, but if I have structured data to track and analyze I always go with Dynamics CRM. When I wrote What if they took the C out of CRM, I was still new to Roman history and didn’t fully appreciate how much more insight I’d gain from it if the historical data were in an xRM application. For example, consider the following figure:

This is the Emperors view of the Romans entity (renamed Contact), with the Emperors by Cause of Demise chart selected. (I customized the Status Reason field for “cause of demise”.)

An application like this demands dashboards. For example, here’s the Emperors at a Glance dashboard:

If I ever need a reminder on who the real stinkers were, I can simply drill down on the 5 bar in the Emperors by Rating chart:

And on the off chance I forget which emperor died because those darned Goths just made him so mad, I can drill down on the Emperors by Cause of Demise chart:

And talk about a perfect use of the Connections feature! Here are just a few of the connection roles I’ve created to keep track of the various ways these people were connected to each other:

I thought it would be fun to compare that against a dashboard I created, the Trick Bag Browser Watch, which is based on the ClickDimensions custom entity, Page Visits. (I’ve written plenty about ClickDimensions, my favorite add-on for Dynamics CRM, so I won’t go into details here. For our present purposes, what you need to know is CD gives you a snippet of HTML/JavaScript, unique to your organization, and you drop it on any page or site you want to do analytics against. As you’ll see below, one of the big advantages of having records like visits and page views in your CRM is that they are tied back to contact records. And while anonymous analytics are interesting, non-anonymous analytics are a lot more interesting!)

With that background, let’s take a look at the revealed browser preferences of Dynamics CRM Trick Bag readers. The next figure shows two different visualizations of all site visits for the last six weeks. The one on the left is by week and browser in case we can see any trends; the one on the right is the all-up distribution for the period:

In my “poll”, you only get to vote once, so everything totals to 100%:

The main difference between Mitch’s results and mine is that about twice as many of my readers access the Trick Bag with IE than with Chrome; Mitch has a slight edge of readers forecasting they will use Chrome to access CRM 2011 when multi-browser support ships with the CRM Anywhere release sometime… very soon.

I mentioned above that analytics are more interesting when associated with something like contact records, which brings me to the next figure. These are the same two visualizations, but this filtered dataset only includes contact page views:

Here are the numbers:

IE accounts for 69% of visits from contacts as compared to its 51% share among all visits. That makes sense: you’d expect my contacts to be a pretty CRM-centric crowd, and CRM’s soon to be former IE-only requirement has created an IE bias in that group.

It will be fascinating to see how these numbers change in the next few months. For most of my clients, I expect the Big Deal
will be the availability, directly from Microsoft, of a rich mobile client for Dynamics CRM on the device of their choice. Microsoft has been clear and consistent on the importance of having a great mobile experience for Dynamics CRM, and I think we can expect that a fast-growing chunk of our CRM interaction will be mobile.

And to the extent that Trick Bag readers are representative of CRM users, I can expect a trend like the one shown here will continue (also from the Trick Bag Browser Watch dashboard):

I guess I better start optimizing those pages for the mobile experience!

A service-level agreement is a negotiated agreement between two parties, where one is the customer and the other is the service provider… The SLA records a common understanding about services, priorities, responsibilities, guarantees, and warranties.

While a simple case routing and escalation workflow isn’t itself a service level agreement, it might include several components of one. In general, service level agreements (SLAs) are more complex, with clearly defined requirements, specific penalties for non-performance, and so forth. There are several problems with trying to implement service level agreements entirely within the Dynamics CRM workflow structure:

• The workflow designer is not the right place to store all of the complex components of an SLA.
• A case routing and escalation workflow is very specific, effectively hardwired for the terms of a single SLA. If you needed to implement SLAs with custom terms for many different customers, the workflow approach would quickly become tedious.

Here we will examine an approach that solves problems like these. Here are some of its characteristics:

• We will use a custom entity, rather than the workflow designer, to represent the SLA. Custom fields will contain SLA-specific information, such as queues to route cases to, escalation periods, and so forth.
• The SLA entity has a 1:N relationship to the case entity. Thus, when a case is created, it can be associated with an SLA record, and a workflow process can use dynamic values to implement the terms of the selected SLA.
• Optionally, we can also create a 1:N relationship from SLA to account. With this in place, the workflow process could automatically check the account record for a specified SLA, and then implement the terms of the SLA automatically for any case created for the account.

How it Works

Before diving into the workflow, let’s take a look at the custom SLA entity. The following figure shows the SLA grid after entering a few sample records:

And the following figure shows the form for a specific SLA record:

The most important aspect of this approach is that the terms of an agreement are effectively variables, with the data stored in the SLA entity: this is how we avoid the hardwired aspect of implementing directly within the workflow designer. Because the SLA entity has a 1:N relationship to both account and case, a lookup field on their respective forms allows a user to select an SLA.

As you can see from the form, the SLA in this example consists of the following components:

• A “Level 1″ queue, where a case will be routed to first; and a “Level 2″ queue for escalation.
• How many days to wait before escalating.
• Which user to assign to cases under the SLA (”Service Rep”).
• An optional incident fee.
• Terms of Service and Non-compliance text fields.

Again, since this is a custom entity with a parental relationship to case and/or account, you can extend it to incorporate arbitrarily complex SLA structures.

Setting Up

The following table presents the customizations to the case and account entities, and the custom SLA entity, that are used by the workflow.

Required Entity Customizations

The Workflow

The Case Escalation and Routing workflow uses the following business rules to determine which SLA to apply to a new case:

• If an SLA has been selected for a case, the workflow leaves it as is. This allows a user to “override” an account-specific SLA.
• If no SLA has been selected for a case but one has been for an account, the account SLA will be applied to the case.
• If neither the account nor case records have an SLA selected, the workflow stops, and no SLA rules are subsequently applied to the case.

The workflow – Case Escalation Process – has organization level scope and runs automatically when a case record is created. I divided it into three stages: the first one determines which SLA, if any, should be applied to the case; the second applies the basic terms of the SLA to the case; the third implements the case escalation logic.

The following figure shows the first stage. All the first stage does is determine which SLA should be associated with the case, according to the rules just described. The Update Case step uses dynamic values to fill in the case SLA lookup with the SLA selected for the account, in the event an override SLA has not been selected for the case:

Once the appropriate SLA is associated with the case, the second stage applies the terms of the SLA to the case.

In the SLA structure implemented here, there are three components to the “terms” of an SLA, all of which are implemented in this stage:

• Field values from the SLA are filled in on the case record by the Update Case step. Since there’s a 1:N relationship from SLA to case this is not strictly necessary…but it’s often quite convenient to have them available on the case record. I get requests like this from customers all the time, and I often swallow hard and implement it like this, weighing the tradeoff between database design purity and ease of customer use. (Not to mention, if you refuse on the grounds of database design purity, you sound like a dweeb.) The following figure shows how the dynamic values are updated in my example, filling in the case SLA fields in a custom section on the case form with the values of the corresponding fields from the SLA record:
  
  • The second part assigns the case record to a Service Rep, if one was specified on the SLA.
  • The third part checks whether a Level 1 Queue was specified, and routes the new case to the appropriate queue.

The third stage performs two main tasks: updates the Escalation Date field based on the SLA’s Escalation Period value, and then implements the Wait…Escalate logic. The following figure shows the collapsed view of the entire third stage, since it’s too big to show in one screen shot:

Here’s the first part expanded:

Remember the goal of this conditional block is to update the Follow Up By (renamed to Escalation Date) field on the case record. Here’s what the properties dialog looks like for the first of the three conditions included here:

The reason this needs to be performed with a conditional block, checking for each possible value of the Escalation Period field, is that dynamic values cannot be used to perform date arithmetic. That is, if you could use the Increment By operator to increment a date field, you could take the following approach:

1. Fill in the Escalation Date field with the Created On date.
2. Increment it by the value of the Escalation Period.

Unfortunately, when this was written date fields only support the Set To and Clear operators. So while this somewhat hard-wired approach is a little inconvenient, it’s not that bad. The most important point is that it allows the user to configure the wait period in the SLA entity, and does not require you to make updates to the workflow itself to accommodate different wait periods.

In any event, after the Escalation Date field is filled in, we’re ready for the wait…escalate logic, illustrated in the following figure. There are three possible outcomes the way I’ve written the process:

• The case might be resolved before the escalation date is reached.
• The case might be canceled before the escalation date is reached.
• The escalation date might be reached before either of those happens, in which case we need to escalate.

We’ve just perfectly described the requirements for a Wait until…Otherwise Parallel Wait Branch… conditional block: a set of mutually exclusive outcomes with a time dependency, and we don’t know which will happen first.

We’ve seen this before in the section on Wait conditions, but it’s worth a review. Here’s what the Timeout until
Case:Escalation Date condition looks like:

Remember, in situations like this is the Process Timeout variable you want to use. The way I think of it, you’re forcing the process to take a timeout until the system clock equals the value of the Escalation Date field on the case record, and this is how you do it.

Here’s an example to show what it might look like as a user creates a case. If necessary, refer back to the figure illustrating the Standard SLA shown above. Suppose Advanced Components has that SLA selected on their account form. A new case is created, with Advanced Components as the customer, and an override SLA is not selected for the new case.

The case is created and saved on February 5, 2012. After the workflow has had a chance to run the case form looks like this:

Notice the workflow has filled in the values in the SLA Information section. If you monitor the workflow process, you will see that everything in the first two stages has happened, and that the process is now waiting in stage 3:

There are plenty of ways to monitor the progress of processes like this. In fact, I often find that the tactics I use to test and troubleshoot processes are also useful to clients after they go into production. For example, many users (including this one!) find the default UI for working with queues and queue items to be a little confusing at times. I usually create a custom dashboard containing lists with specific views of queue items so I can verify that items are being correctly routed to queues. Here’s an example that makes it obvious that the case just created did actually get routed to the correct Level 1 queue:

Summary

The approach discussed here effectively substituted a custom entity – the SLA – for what might otherwise be accomplished by implementing custom business logic, hardwired for a specific SLA, in the workflow designer. Provided the SLA entity has a parental relationship to case, dynamic values can be used to grab SLA-specific data from a customer’s SLA when a new case is created. SLA creation and maintenance becomes a task business users can perform, and workflow designers can do other things, such as go skiing or watch the White Sox or the Mariners, or both.

The approach can be generalized to non-service scenarios also. The general idea is that you have a “configuration” entity to store specific combinations of values for various configurations. Any record type with an N:1 relationship to the configuration entity can be populated with data from one of its records. Here are a few examples where you could apply the general approach:

• Use an “opportunity type” entity to store combinations of data to use on different opportunity types. When a user creates an opportunity and selects a type, you could attach appropriate templates or sales literature, notify appropriate users, update with the appropriate price list and so forth.
• Use an “event type” entity, and create a 1:N relationship from it to the service activity entity, updating specific information on a service activity record when an event type is selected.
• Use a “product type” entity, and create a 1:N from it to product, auto-populating information on a product record based on the selection of product type.

A final note: this article is adapted from an example in my upcoming book, which I will soon be able to refer to simply as my book. Look, it’s even got a cover design (thanks to my publisher, the indefatigable Julie Yack):

I’ve posted plenty of other excerpts and examples in the Workflow and Dialog Processes article category, and I’ll present some of my favorite business process tips & tricks in the webinar scheduled for May 31.

forific l, service level agreements (SLAs) are more complex, withhe wait period in the SLA entity, and does not require you to

I recently posted a video on my YouTube channel that clarifies some of the least intuitive aspects of Dynamics CRM security roles, and rather than bury it at the end of what’s already a borderline too-long article, I thought it better have its very own article.

In the video, I walk through a custom security role for what I called the “Summer Intern” scenario, and the most important points it should clarify are the following:

• The difference between the Append and Append To privileges. The Append privileges you have for an entity determine whether you can append it (add it as a child record) to other records. Append To privileges for an entity determine whether you can append other records to it. Whenever I cover this topic in training, I always have to repeat the previous two sentences to myself several times before hand, so I know for sure it’s one of those topics that could use a good demo. Here are a few examples. Suppose your security role has:
  • Append privilege for the Activity entity set to Organization; Append To for Account set to None; Append to for Contact set to User. This means you cannot add any activity records to any accounts (you won’t see the Add ribbon on the account form), but you can add activities to contact records provided you own the activity.
  • Append To for Account set to Organization, Append for Contact set to Business Unit, Append for Opportunity set to None. This means you can associate a contact record with any parent account record, provided that the contact record is owned by you or any user in your business unit. You won’t be able to associate an opportunity record with any parent record…which means you won’t be able to create one because the Potential Customer field is required.
• The Create privilege. I get lots of questions about this one, and for some reason I didn’t cover it much if at all in the security article I mentioned earlier. The video definitely calls this one out, but here’s a short explanation: the Create privileges you have for an entity determine which users you can create a record for:
  • If set to None, you can’t create any records and you don’t see the New button on the ribbon.
  • If set to User, you can only create records and assign them to yourself.
  • If set to Business Unit, you can create records and assign to you, or any users in your business unit.
  • Parent-Child Business Unit: can create and assign to you, any users in your business unit, or any child business units.
  • Organization: can create and assign a record to any user in the entire CRM organization.

  I get a lot of questions about this one, and I think the reason is that it seems like it should be covered by the Assign privilege. It isn’t though: think of Assign as controlling your ability to assign records after they’ve been created. Create controls what happens the first time a record is saved. There’s an analogy to this in workflows and dialogs, by the way. What you’ll notice there is that when a record is first created, the Assign event is not triggered. So if it’s important to notify a user that a record has been assigned to them, you need to use both the Record is created and Record is assigned triggers: In a technical sense, when a record is created it’s not assigned (even though in a practical sense it is, since it has an owner!)

• Miscellaneous Privileges. Most of these are found on the security role’s Business Management tab. These have to do with things that are NOT entity-specific, such as Export to Excel, Bulk Edit, Print and so forth. Most of these are all or nothing: full green Organization or empty red None. If set to None, the button in question (Excel, Merge with two records selected, Edit with multiple records selected, etc.) just doesn’t show up on the ribbon.

Here’s the video. Enjoy.

So…register now for the 90-minute session, May 31, noon CDT. Topics include, but not limited to:

• What can you NOT do with business processes?
• What can you do with processes that can not be done interactively?
• Working with closed records and read-only fields
• Working with hyperlinks and record URLs
• Security: who can run ‘em, who can create ‘em?
• Dialogs: when to query, when to look up?
• Dialog Power-Tip: run dialogs from dashboard links
• Workflows v. Dialogs: Round-Robin assignment and cloning records

In the webinar I referred to several pages and resources for more information, so I posted the links here:

The Q2 2012/CRM Anywhere/R8 Release

http://crmpublish.blob.core.windows.net/docs/ReleasePreviewGuide.pdf

Dynamics CRM and SQL 2012: Better Together

http://blogs.msdn.com/b/crm/archive/2012/03/07/microsoft-dynamics-crm-and-sql-server-2012-better-together.aspx

The Dynamics CRM Marketplace, (a search for solutions from Microsoft Dynamics labs)

http://dynamics-crm.pinpoint.microsoft.com/en-US/applications/search?q=microsoft+dynamics+labs

CodePlex, (a search for CRM 2011)

http://www.codeplex.com/site/search?query=crm%202011

Social Analytics (“Vancouver”) in R9 timeframe

http://www.microsoft.com/en-us/sqlazurelabs/labs/socialanalytics.aspx

Single Sign-on and Synchronized Users

http://msdn.microsoft.com/en-us/library/hh675418.aspx

http://onlinehelp.microsoft.com/en-us/office365-enterprises/hh125004.aspx

IDC June 2011 Study on Public IT Cloud Services Spending

http://www.idc.com/getdoc.jsp?containerId=prUS22897311

I use (and highly recommend) the ClickDimensions marketing automation solution, which lives inside Dynamics CRM and provides visualizations like the following one:

That figure illustrates the form of the Email Send entity (or in non-PC terms, the Email Blast), and the fact that all of those events (Delivered, Opens, Clicks, Bounces, etc.) are associated with contact records is what we mean by email tracking and like I said, when I first started out that was what mattered.

Why Analytics Matter

But the longer I do marketing automation the more I appreciate the importance of other feature areas. For example, ClickDimensions (CD) provides its customers with some tracking script (analogous to what you might get for Google Analytics), and you can embed it in your web site’s HTML to track activity such as site visits and page views. The tight integration of the CD solution with CRM means that visits and page views are implemented as custom entities, so after turning on the tracking script you can see things like the following figure, which shows several records of the Visits type.

The highlighted columns are Lead and Contact, and begin to illustrate why the analytics features are so important as a complement to email tracking. If all your web site traffic was anonymous, you might as well use Google Analytics. But the ability to associate visits and page views with your customer or potential customer records is a powerful thing, and I’ll show you a specific example of this next.

The Importance of Being Non-Anonymous

A visitor to your web site might view multiple pages. The previous figure showed several Visit records, and you can probably guess that ClickDimensions also provides a Page View record type. And as with visits, the distinction between anonymous and non-anonymous page views is an important one. I get a dramatic reminder of this every time I send out one of my Dynamics CRM News You Can Use emails. For example, the most recent was the Convergence 2012 edition, which went out on March 22. The next most recent was the February 2012 email, sent on Feb. 29. (Thank goodness this was a leap year!)

The easiest way for CD to associate a page view with a contact is when the page view is from a link in a sent email. So I suppose it’s not surprising that non-anonymous page views spike immediately after an email goes out. In my experience, though, the non-obvious thing is the importance of the non-anonymous (contact) views in driving overall page views.

You can see this phenomenon in the following table.

The top chart represents all page views, by day, for the last 30 days. The bottom chart represents, for the same time period, a subset of page views: only the ones from contacts.

Those two charts are from a custom dashboard I built (which again illustrates the importance of the tight integration of CD with CRM: page views is a custom entity, so you can build charts and dashboards, custom workflows, and use all the standard customization techniques). The most obvious fact is how page views by contacts spike after an email goes out. (I know it’s hard to read; the last two emails I sent out account for the spikes on 2/29 and 3/22.) The less obvious one is how those contact views impact overall page views. Almost invariably, the days with the most overall page views are the same as the ones with the most contact page views, and that pattern holds true for the time period in the table.

Another slice of the same data is by page, and an example of this is shown in the following table.

The top chart shows the top ten pages on my blog, stack-ranked by number of page views for the last seven days. The data set for this chart includes all
page views. The bottom chart is the same, except for a different subset of the data: only page views associated with a contact record.

The highlighted bars represent page views for the Convergence 2012 Highlights page. That page’s share of all page views is about 15% for the last week, but its share of pages viewed by contacts is well over half. This has a couple of possible interpretations: either my contacts are more interested in the Convergence 2012 Highlights session than anonymous visitors, or the email blast (that included about ten links to the Convergence Highlights session landing page) was effective. Or a combination of the two.

Either way, it’s good to know, and it’s the sort of thing you really can’t know without thoroughly integrating your marketing automation and customer relationship management efforts.

Microsoft Dynamics CRM General Manager Dennis Michalis delivered the keynote for the CRM track on Monday. He identified four Big Trends for CRM, and talked about how they’re reflected in his team’s development efforts. I can’t think of a better organizational theme for an article like this one, so with thanks to Dennis, let’s dive in:

Big Data

Big data just keep getting bigger, and certainly customer relationship management applications contribute their fair share of the 2.5 quintillion bytes created on a daily basis (according to the Wikipedia Big Data page). It’s safe to say that the built-in tools Dynamics CRM has for reporting on, analyzing and visualizing data have not kept up with the application’s ability to handle large data sets. But that’s going to change over the next few months, especially as some key technologies from SQL Server 2012 find their way into the feature set.

For Dynamics CRM, the big news in the Big Data category is that the Q2 2012 service update will fully leverage the just-released SQL Server 2012. On the reporting and analytics front, we’ll be able to use the Power View SSRS add-in. It will be available in the form of Power View templates available for download from the Dynamics CRM Marketplace.

Of course, Big Data need a lot more than reporting and analytics. Read this article on how the rest of the improvements in SQL Server 2012 will make Dynamics CRM more scalable, reliable and secure than ever.

Cloud

Dynamics CRM Online, launched in April 2009, blazed the cloud trail for Microsoft’s business applications. Three years later it’s got a lot more company, with Office 365, the Azure development platform, and upcoming online ERP options for Dynamics NAV and AX. Microsoft customers’ cloud migrations started with a trickle, have become a steady stream, and could become a torrent if Microsoft executes on its aggressive plans.

Various flavors of Office 365 include the desktop applications, plus SharePoint, Exchange Online and Lync. Azure provides a cloud infrastructure for custom development. And the upcoming cloud options for NAV and AX means that, for a wide variety of organizations, an all-cloud infrastructure (i.e., no infrastructure as far as IT is concerned) will be possible.

While Microsoft is uniquely positioned to make the investment required for plans as aggressive as these, plenty of execution needs to happen as well.

In my view, the biggest current execution gap in Microsoft’s business cloud offerings is single sign-on, or identity federation. This is the latest example of something that’s simply too difficult to be feasible for many of the SMB organizations who otherwise would be prime candidates for a cloud infrastructure. For example, the ten-step process outlined on the single sign-on roadmap page looks like a recipe for another kind of ten-step program.

Social

Social CRM has gone from curiosity to mainstream in the two years since I referred to Convergence 2010 as the Social Convergence. And while it’s still as hard to precisely define it as it is easy for parents to embarrass their kids on Facebook, Microsoft has staked out a leadership role in the social CRM space. The Activity Feeds feature (released in the November 2011 service update) was a start, but Microsoft has aggressive — and very near term — plans to build on that initial investment.

In my view, the most important new items on the social CRM front is the following:

• Activity Feeds will be enhanced in the Q2 service update, with the ability to Like or Unlike posts, and improved post filtering capabilities such as (especially!) making data views available to filter posts (e.g., My Accounts, Opportunities Over $1M closing in the Next Month and so forth)
• A LinkedIn integration will be available as a managed solution, downloadable from the marketplace. I assume it will be free, although I did not hear that word used to describe it.
• An InsideView mashup will apparently become part of the core Dynamics CRM feature set. I once described InsideView as the ultimate Dynamics CRM mashup and I use it every day, so I’m really looking forward to this one.

CRM Anywhere

Multiple browser support comes to Dynamics CRM in the Q2 2012 service update. Aptly referred to as the CRM Anywhere release, we (finally) will get support for Safari, Firefox and Chrome. And maybe even more important is the exciting news that native mobile clients will be available for iOS, Android and Windows Mobile platforms.

In addition to all flavors of IE, the supported browsers will be:

• Safari running on Mac or iPad
• Firefox running on PC or Mac
• Chrome running on PC

The update will also include an enhanced mobility experience called Microsoft Dynamics CRM Mobile. This is a new cloud-based, cross-platform native mobile client for Windows Phone 7.5, iPad, iPhone, Android, and Blackberry devices. This is a native client app — not a browser solution – so the mobile CRM experience won’t require an Internet connection, and will leverage the cool features of each platform.

CRM Online customers will be able to purchase mobile client apps directly from Microsoft in the Dynamics CRM Marketplace for $30/user per month; on-premise customers will need to continue to purchase a rich mobile experience from third party vendors such as CWR Mobility, the company Microsoft partnered with on the Microsoft Dynamics CRM Mobile application.

For a comprehensive statement of the new features coming this spring, visit the Q2 2012 service update/CRM Anywhere release page

In part 1 of this series I explained how you can apply the goal management features of Dynamics CRM 2011 to marketing automation scenarios. I use the ClickDimensions add-on solution, and the goals I discussed in the first article were for email marketing clicks; specifically, how to build and track progress against goals for clicks from my monthly Dynamics CRM News You Can Use emails. The end result was a chart like this one:

Clicks are nice, and as I said in the first article they are a necessary starting point. But for most organizations they aren’t enough, since they’re usually just a stage in a larger process. For example, suppose you visualize an email marketing pipeline with a funnel chart like the following one:

The great thing about an add-on like ClickDimensions is that all of these actions are tracked in CRM, and they’re all associated with your customer records. Last time I showed how to track progress against click goals. In this article we move on to conversions.

Background: ClickDimensions Forms

After an email recipient clicks a link, what do you want them to do next? Well, if they click through to a form you generally want them to provide some information and click the submit button. You can think of converting a click into a more committed activity: maybe it’s a purchase, a request for a discount coupon or for a white paper. In the scenario I’ll describe next, it’s a registration request for an upcoming webinar I’m delivering on April 4, Convergence 2012 Highlights.

Building a Form

Like the rest of the components in ClickDimensions (CD) marketing automation add-on the form designer is simple to use and gets the job done. In CD terminology, forms are a type of Web Content, which is a custom entity contained in the CD solution. (The other types of web content are surveys, landing pages, and subscriptions.) Here’s the form designer, opened from the context of the Web Content form for the Convergence 2012 Highlights form I wanted to create:

Designing a form is a simple drag and drop process. Forms are designed to capture information to the lead or contact entities in CRM, and you can map form fields to system or custom CRM fields, as you can see from the custom “Coupon Request” field in the previous figure. In addition to data fields, you can drop other components such as HTML or a CAPTCHA widget directly onto a form. You can set field and overall form properties, preview the current version of the form, optionally create an auto-responder using a CD email template, and a few other things.

Deploying a Form

When your form’s ready, you can click the Embed button to copy the Iframe code to the clipboard, then paste it into the HTML of a web page. Here’s an example of a deployed form (the Convergence 2012 Highlights form I mentioned previously):

Posted Forms

Once a form is deployed you start to really appreciate the advantages of having forms integrated with a marketing automation solution. The following figure is pretty much the money shot:

The two highlighted columns (I made them skinny to obscure the names) are Contact and Lead. The way CD forms work, a search is performed when a form is submitted (when a Posted Form record is created, in CD lingo). If a contact record is located, the posted form is associated with that contact. If not, a new lead record is created and associated with the posted form. And if the lead record is then qualified to a contact, the posted form is associated with both!

Goals

Now that we know how to build and deploy forms, and how the posted forms come into CRM, we’re ready to set and track progress against goals. Establishing goal targets for clicks (the topic of the previous article) can be difficult, especially when you’re just starting out. It gets easier over time, as you get more experience and gather more data, and especially if you send marketing emails on a regular basis. But in some scenarios it’s easy to set a goal target. For example, for my upcoming Convergence 2012 Highlights webinar, I’d like about 50 attendees. Since there’s always some drop-off for a free online session, I’ll go with a target of 60 and a stretch target of 70.

Remember, the form I’ve referred to a couple of times allows a visitor to request registration for the webinar. When the form is submitted the request comes into CRM as a posted form record, so the goal I create needs to be for posted form records.

Building the Goal Metric

And if you know a little about goal management, you know that means you need a goal metric for the posted form record type. Here’s what mine looks like:

The metric type is count, I selected the Track Stretch Target option, and I defined a single rollup field for the Posted Form record type. Notice that there’s an actual rollup field but no in-progress. That’s because, like clicks, form submits are discrete events: they either happen or they don’t, so there’s no in-progress state. Here’s what the rollup field looks like for a goal metric like this one:

Building the Goal and the Rollup Query

With the goal metric in place, I can create the goal. The following figure shows the General, Time Period and Targets sections of my goal form:

Here are the things to notice from the previous figure:

• It’s based on the Form Submits metric reviewed above.
• The custom time period ends the day of the seminar. Unlike the previously discussed goal for clicks, a goal for webinar registrations has a clearly defined end date!
• The Stretch Target field shows up because I selected that option on the goal metric.

The following figure shows the Actuals and Goal Criteria sections from the bottom of the form:

If you read the previous article, you probably guessed that this goal would require a rollup query. In this case, the rollup query is required to specify which posted form records should roll up to the goal. It looks like this:

It’s defined for the posted form entity type, and the query specifies that only posted forms related to the Convergence 2012 Highlights form should roll up. (Remember: the form entity is the parent of the posted form, so we can use that relationship to build the query.)

Charts and Dashboards

As with other goal management charts and dashboards, the ones I use for this scenario are quite specific. The following figure shows a dashboard I find useful; all it does is add a single Goal Progress chart for form submits (webinar registration requests, that is) to the one I showed at the beginning of this article.

Summary and Homework Assignment

I’ll close with a couple of related points. First, even a cursory glance at the goal progress chart for webinar registrations indicates I’m not where I should be. Since this goal has such a short time period (from March 1 to the April 4 webinar date, remember) the Today’s Target metric is actually interesting. And with 13 requests (22% of the 60 target value) my actual is less than the Today’s Target value of 27. But I’m not overly concerned yet: Convergence 2012 is next week, and that’s the perfect time to send my special March 2012 Convergence edition of Dynamics CRM News You Can Use, which will prominently feature links to the Convergence 2012 Highlights page, and should drive plenty of requests.

This brings up my second and final closing point. You may wonder what any of this has to do with email marketing, the marketing pipeline funnel and all that. All I’ve done so far is built and deployed a form, created a goal for form submits and talked about tracking goal progress. Where does the marketing come in? That happens next week. So far the registration requests have all been from what you might think of as organic traffic: I published the page on Tuesday and had 13 registration requests on Wednesday and Thursday. So how does the goal measure marketing efforts? Well, my blog is a marketing vehicle, so it does measure that, but it doesn’t really measure email marketing efforts.

That’s the homework assignment: the goal I described here is an overall webinar registration goal, but if I want one to focus in specifically on email marketing’s contribution, I need to narrow it down a bit. Let me know if you’ve got the perfect solution to this. I’ve got at least one in mind, and there’s a clue in the screenshot in the Posted Forms section above.

In the meantime, if you’d like to participate in my ongoing experiments in Dynamics CRM-centric marketing automation, fill out this form to become a subscriber.