Nurture Marketing

• Traditional marketing was essentially a 1:N model, with nurture, the goal is to create a personal, 1:1 relationship with a client.
• Traditional marketing was event-based, with every activity essentially an independent event. In contrast, nurture marketing is relationship-based, with activities part of an ongoing conversation, each activity making use of information gathered from all the others.
• Traditional marketing was targeted at a demographic, at best. With Nurture marketing the goal is to create a tailored set of activities, specifically crafted for an individual.

• Drip marketing is where a pre-determined set of emails go out, one after the other…drip…drip…In this context, a good example would be the confirmation email you get when you register for a seminar; then the day-before reminder, then the post-event email with a link to a session evaluation. Another drip marketing scenario was described in a ClickDimensions blog post from last year.
• Trigger marketing is more adaptive – where specific marketing activities depend on a customer’s behavior. You could inject a trigger component into the webinar example by sending a different post-event email depending on whether somebody attends or doesn’t. I showed a different application of trigger marketing in Dynamics CRM in my demo, using CD as the foundation, combining it with a custom Dynamics CRM workflow.

• I send out my monthly email newsletter using CD. If I send an email and it bounces, an automatic workflow creates a Bounce Followup task for the record owner.
• If it doesn’t bounce, we wait to see what happens
• If nothing happens for a certain number of days, we send another email – maybe with a reworded subject line
• But if before then we get an open we take a different path: wait for a click and if we get one create a Click Followup task for the record owner.

• The first one tests for a click-through, and creates a click followup task if appropriate.
• Next, if an email bounces we create the bounce followup task, and as a best practice I go straight to LinkedIn when that happens.
• And if neither of those two things happens, we sit and wait for 5 days, eventually sending a second email, generally with a re-worded subject line so as not to be tedious.

Surveys

Here’s the note I received:

Hi Richard,

I heard you speak at Extreme last year. I have been stumped on something and was wondering if you had time to help a noob with a weird problem. Maybe make a blog post out of it? I apologize if this is not the right way to beg for help.

We have a custom entity called a Project, from which multiple Marketing Lists hang off of it. Using javascript triggered from the Project, we want to be able to create marketing lists and associate the new marketing list with the Project. I can’t seem to figure out how to associate it with the Project. I can make the Marketing List, fill in the all the correct information, but am failing at the association with the project.

I tried using some code from here:

http://stackoverflow.com/questions/7358482/how-to-link-two-records-with-javascript-and-a-nm-relationship

to use this call:

AssociateEntities(data.ListId, “ListSet”, Xrm.Page.data.entity.getId(), “ags_projectSet”);

Am I passing the IDs incorrectly? Not sure. Is this code sensitive to there being curly brackets around the IDs? For the xml, how do you know which object to put first? Is this the wrong piece of code since I am trying to fill in a 1:N relationship instead of N:M? Any help you can give me would be awesome. Thanks.

on this function:

function AssociateEntities(id1, entityType1, id2, entityType2, relationshipName) {

    var xml;

    var resultXml;

    xml = “<Execute xmlns=’http://schemas.microsoft.com/crm/2007/WebServices’>”;

    xml += “<Request xsi:type=’AssociateEntitiesRequest’>”;

    xml += “<Moniker1><Id xmlns=’http://schemas.microsoft.com/crm/2006/CoreTypes’>” + id1 + “</Id>”;

    xml += “<Name xmlns=’http://schemas.microsoft.com/crm/2006/CoreTypes’>” + entityType1 + “</Name></Moniker1>”;

    xml += “<Moniker2><Id xmlns=’http://schemas.microsoft.com/crm/2006/CoreTypes’>” + id2 + “</Id>”;

    xml += “<Name xmlns=’http://schemas.microsoft.com/crm/2006/CoreTypes’>” + entityType2 + “</Name></Moniker2>”;

    xml += “<RelationshipName>” + relationshipName + “</RelationshipName>”;

    xml += “</Request></Execute>”;

    var xHReq = new ActiveXObject(”Msxml2.XMLHTTP”);

    xHReq.Open(”POST”, “/mscrmservices/2007/CrmService.asmx”, false);

    xHReq.setRequestHeader(”SOAPAction”,”http://schemas.microsoft.com/crm/2007/WebServices/Execute“);

    xHReq.setRequestHeader(”Content-Type”, “text/xml; charset=utf-8″);

    xHReq.setRequestHeader(”Content-Length”, xml.length);

    xHReq.send(xml);

    resultXml = xHReq.responseXML;

    if (resultXml) {

        return “success”;

    }

    else {

        return null;

    }

}

• If the people you want to survey are in your CRM (e.g., as contacts), taking a CRM-centric approach is compelling. This is the same argument as using a CRM add-on solution for email marketing rather than, say Constant Contact: survey results might be as important a piece of customer history as email click-throughs, so it’s natural to want them in your CRM.
• The kind of surveying and profiling described next can be done with the out-of-the-box CRM feature set plus a few customizations, so you won’t pay additional licensing fees or have to learn a new application.

• Complex survey functionality will be more easily implemented with a dedicated survey application. As you’ll see, using Dynamics CRM for a job like this one is a bit of a DIY project, and as with all DIY projects, you’re essentially making a build v. buy decision.
• Dialog processes must be run by a licensed CRM user. So if you need to provide a self-service survey option, the CRM-centric approach discussed here won’t be an option.

1. Profiling and Surveying Customers: The Goal

   This approach I’ll describe here requires some customizations, and there are many different ways of implementing it: from simple and specific, to complex and flexible. Let’s start by examining how this surveying solution works, so you know what we’re shooting for.
   Some organizations have highly structured “onboarding” process to be applied when new customers are signed up. For example, a bank might have a standard set of questions to ask of new savings account customers, or a marketing department might want to know if a new customer was influenced by any of its ads, mailings and so forth. Other common requirements of onboarding processes like these are to get feedback from the customer on their overall satisfaction level and to confirm that important information on the customer record is correct.
   The following figure shows the single page of our dialog process as it’s being run by a user. This process is written for the contact entity, and you can see in the first (highlighted) prompt that we’re using dynamic values to provide the user with a customized script (Hello, Eva) and to call attention to some of the most important contact information we want our user to verify or correct.
   Notice also that in the Tip section we’ve provided a link (Navigate to contact record) and instructed the user to go directly to the contact form if they need to make any changes:
   
   The next figure highlights the How did you hear about us option set. You’ll see below that we used a custom entity to store these values, and a query in the dialog process to present them to the user.
   
   The following figure presents the “rate your overall experience on a 1-5 scale” question.
   
   After the user clicks the Finish button, the process creates three records for a custom entity, Survey Response, one for each of the questions. (It might look like there are four, but remember the first one is just a prompt, with no response being captured.)
   The following figure illustrates that the Survey Response entity has an N:1 relationship to contact, so our design requirement of having survey responses be part of the comprehensive customer history is satisfied:
   
   Here’s the data grid for survey responses with the All Survey Responses view selected. Notice that I’ve added several different fields to store different kinds of responses. This is an important detail and I’ll describe it more fully below.
   
   Finally, the following figure really starts to highlight some of the potential benefits of this approach. A custom view filters survey response records to only include records for the Experience Rating question. This means that a custom chart can be used to visualize the results:
   
   Here, the chart is constructed with the average value of the Response (Decimal) field as the Series, and the data are distributed across the owners of the underlying contact records.

2. Setting Up

   I used three custom entities to implement this solution: Survey, Survey Response, and Lead Source. The following Visio diagram illustrates how they’re related to each other and to Contact:
   
   Contact and Survey both have 1:N relationships to Survey Response, effectively creating an N:N between Contact and Survey. Notice that Lead Source isn’t related to anything. Of course, it could be related to other entities, but for this example it is not required to be. As you’ll see below, the only role the Lead Source plays here is to allow us to query the values so we don’t have to enter them in the dialog designer!

   Entity		Custom Fields	Field Type and Purpose
   Survey		Survey Name	Single Line of Text.
   		Survey Date	Date and Time.
   Survey Response		Name	Single Line of Text. Auto-filled by workflow.
   		Question	Single Line of Text.
   		Respondent	Lookup to Contact entity. Creates a custom 1:N relationship from Contact to Survey Response
   		Survey	Lookup to Survey entity. Creates a custom 1:N from Survey to Survey Response.
   		Response (Whole Number)	Whole Number.
   		Response (Decimal)	Decimal Number. This is important for reporting and charting, and is the appropriate field type for most numeric survey responses.
   		Response (Short Text)	Single Line of Text.
   Lead Source		Lead Source Name	Single Line of Text.

   After creating and publishing these customizations, customize the security role of any user that will be conducting surveys. This is an important step: it’s easy to forget, and if you don’t do it the dialog process will not work! The way I’ve written the dialog process, it creates the survey responses and assigns them to the owner of the contact providing the responses. Survey Response is a custom entity, and by default no security roles except System Administrator have privileges to custom entities. The following figure shows the minimum privileges required for this to work (user-level read privilege for the Survey Response entity), assuming a participating user has the Salesperson security role:
   

3. How it Works

   The dialog process is written for the Contact entity, and is only available to run on-demand. To make it easier to understand I built it with three stages, shown collapsed in the process designer here:
   
   Stage 1 only does one thing: uses Query CRM Data to build a static query for Lead Sources:
   
   Stage 2 contains the dialog’s single page, with four Prompt and Response pairs:
   
   The first Prompt and Response is actually a prompt with no response:
   
   Note the use of dynamic values in the prompt, to both personalize the conversation and display some of the most important fields from the contact record. Also of interest is the use of the dynamic record URL in the tip text. This important functionality was first introduced in the November 2011 Service Update and it allows you to dynamically generate a link so the user can easily open a record’s form from the context of the dialog process.
   The Insert Hyperlink icon is available both for Prompt Text and Tip Text. The following figure illustrates how I constructed the link for this example, which I then combined with static text to provide complete instructions to the user:
   
   The next figure shows the Prompt and Response properties for the Source. Rather than entering the values within the dialog designer, I queries the Lead Source custom entity.
   
   If you wondered before why I took that approach, now you can probably appreciate the design decision. Even though it took a little work to set it up, here are the three main reasons I chose this approach in the present example:

• It’s much easier for a user to maintain Lead Source values as an entity than it is to customize the dialog process itself.
• Something like Lead Source is a good candidate for re-use across different entities. For example, there’s an option set field with the same name available on the lead entity in CRM. I generally prefer the custom entity approach over the option set approach, and keeping track of lead sources is a pretty common requirement. So even if my only current requirement for a lead source lookup is within this dialog process, chances are good another one will come along later, and I’ll be ready when it does.
• It’s time-consuming and tedious to enter hard-wired values in the process designer in the first place!

1. Reporting, Charting, Extensions and a Few Tips & Tricks

   This example raises a number of interesting issues and there are several different design decisions you might consider. I’ll review a few of those here.

• I mentioned a couple of times the importance of using the Decimal Number data type for the experience rating response in this example. You might think that the Whole Number data type would work just as well, and in fact, I’ve (mistakenly) taken that approach at least twice now. Why would it be a mistake for this solution? To understand this, consider again the chart I showed above:
  
  Notice that the average values displayed on the chart include two decimal places. If instead of placing the experience rating response into a Decimal Number field I’d placed it into a Whole Number field, the charting engine would display every data point with no decimal places, rounding it up or down to the nearest whole number! It’s not clear to me why the charting engine does this, but it does, so be sure to use the Decimal Number field type if you want to use the built-in charting and dashboarding features in CRM for applications like this.
• Another data type anomaly lurks in this example as well: the difference between the Single Line of Text and the Multiple Lines of Text field types. Remember that in the approach I took, the source response was placed into a Single Line of Text field. That allows me to create a chart that shows how contacts are distributed across Lead Sources, like this:
  
  To create a chart like this, you first need an appropriate view to filter down to the right question type, and then you can create the chart in the Chart Designer, like this:
  
  The first time I tried this I stored a response to a Multiple Lines of Text field, and in the chart designer I couldn’t use it as the Category field: it just doesn’t show up. So, just remember: if you want to see counts of how records in a view are distributed across various values of a text field, make sure it’s a Single Line of Text field.
• Possible extensions. Remember how I used Query CRM Data so I wouldn’t have to enter the Lead Source values manually in the process designer? And remember how in the experience rating prompt/response step I entered them manually? Well, suppose you needed to create a survey with several separate rating type questions, and suppose further that they were all on a 1-9 scale. (I once owned a training company and for years we gave students post-class evaluations on 9-point scales to rate things like the instructor’s subject matter expertise, courseware quality, facility quality and the overall value of the learning experience, so I know for a fact people perform surveys like that.) Anyway, manually entering the first set of nine values might not seem so bad, but as you entered the second set you’d probably wonder if there was a better way. And by the time you got to the third set you’d be tempted to just go with a paper-based process instead!
  If you do have surveys that require multiple questions of the same type (the same rating scale, for example), there are better approaches you can take. For example, consider the following figure:
  
  This is a custom entity – Possible Survey Responses – with two fields: Response Type is an option set, with values such as Three point scale, Five point scale and so forth. There’s a single record for each possible response for the response type, with an appropriate value in the response value field. You can then take advantage of a custom entity like this in the dialog design process, querying the entity for the possible response values for each response type, as the following figures illustrate.
  Suppose you start by building queries for the different kinds of survey questions a survey has:
  
  Each query is simple. The next figure shows the properties of the Five point scale query, which simply filters on the Response Type option set:
  
  Once you’ve done that, you’re all set for the Prompt and Response steps, since you can get the option set values directly from the queries, rather than entering them manually:
  

Anyway, let me know what you think. What kinds of interesting applications have you come up with for dashboards in Dynamics CRM 2011?

Here are six examples of how you might use dashboards, followed by a few dashboard implementation tips to keep in mind.

Example 1: Tracking User Activity and Record Creation

This dashboard provides a heuristic visualization of user adoption. The top row shows 3 charts, each one displaying counts of records created over the last 6 months for selected record types. The bottom row shows a different slice of the same data: for each record type over the same time period, which users created the records?

Here’s an article I wrote recently describing an approach to track and score user activity.

Example 2: Metrics and KPIs for Custom Record Types

Whether you’ve created your own or imported them as part of a solution, remember that custom entities are just as “dashboard-able” as anything else. For example, the one I show in the next figure uses the custom Page View entity that’s part of the ClickDimensions managed solution for marketing automation in Dynamics CRM. After getting provisioned with their solution and dropping some tracking script on your web site, page view records start getting created automatically. All I had to do for this one was create a couple of custom views and charts. (And notice the Trick Bag almost hit the 10,000 page views in a week milestone last week!)

Example 3: My Activities

OK, enough with the pretty pictures. Another good use of dashboards is to help users do something. One of my favorite examples is what I refer to as the My Activities dashboard. Two things about this one I like a lot:

1. It makes sense for every user, since it uses slightly tweaked “My Activities” views to filter out all records not owned by the current user.
2. It encourages good activity management by making it easy.

It contains two lists. The top one is for open activities, sorted by Start Date (you can also use the Due Date field) in ascending order, so you see first things first. If you’re keeping your activities up to date, there shouldn’t be anything in that list earlier than today’s date. The second one is for completed activities:

The nice thing about this is that if you expose a list on a dashboard, the ribbon for the list is exposed as well. In this case it means that a user can use the Mark Complete button to push something from the top list to the bottom:

Simple, but useful!

Example 4: Launch Dialog Processes

I wrote a detailed how-to article on this topic, but this technique is definitely general enough to include here. Dialogs can be launched with a URL, and you can use JavaScript and web resources to do things like dynamically figure out the current user and so forth. I’ve got a client for whom internal lead referrals are very important, so I created a “My Referred Leads” dashboard that lets a user both kick off a lead referral dialog session as well as see what’s happened to leads they’ve previously referred:

Example 5: Links to Commonly used Views and Reports

Here’s a slightly different take on the “put a link on a dashboard” theme. This dashboard in this example consists of a single HTML web resource that contains hyperlinks to views. Remember that every view in Dynamics CRM (similarly to forms, dialog processes and so forth) is addressable via its very own persistent URL. You can exploit “URL-addressable forms & views” to create the ultimate KISS dashboard, such as the following one:

In the previous figure, if I click Hot Opportunities and the JavaScript in the HTML web resource is written right, the Hot Opportunities view will open in its own window:

Example 6: Use HTML Web Resources for Training/Documentation Content

Another way to push user adoption is to make it easier to access things like training content, system documentation and so forth. The following figure shows an example of this. These are all simple, straight HTML web page resources with nothing but text. But with a little more work you could embed links to the views mentioned in the content, links to demonstration videos, more detailed content and the like:

A Few Dashboard Implementation Tips

Here are a few dashboard factoids that weren’t obvious to me when I first started working with them:

• System dashboards can only be created by system administrator-type security roles, and are visible to all users who can see dashboards. This means you can’t target system dashboards, so if you only create system dashboards you might end up with a LOT of dashboards and a cluttered user experience.
• Personal dashboards can be created by any user and by default can only be seen by that user. But they can be shared (to users or teams), so if you want to create a targeted dashboard experience, consider creating personal dashboards and sharing them.
• System dashboards cannot contain personal views or personal charts.
• Personal dashboards can contain personal views and charts, OR system views and charts.
• But remember: if you try to create a targeted dashboard experience by creating a personal dashboard and sharing it, remember to share out any views or charts used in the dashboard!

• They provide visualization, but they don’t really provide a measure.
• They don’t scale very well. For example, if you need to measure and compare usage for dozens or more users, they won’t be very effective.

• For activity records, it’s completed ones that matter. Canceled ones don’t count.
• Contacts and accounts – the customer records – are worth more than a completed activity.
• And while opportunities are worth something to create, they’re worth even more to close as won!

Setting Up

• A single custom field is added to the user entity to maintain an all-up “total score” value.
• And because it might be important to report on a user’s score over different time periods, I use a custom entity – Activity Counter Records – to store the detail on every activity contributing to the overall score.

How it Works

• Create an activity counter record with the appropriate values, and associate it with the user performing the activity being scored.
• Update the aggregate score field on the user’s record.

• If all you need to do is track an aggregate score for each user, you don’t need the custom entity I used (activity counter). But remember, if you don’t have that you lose the time dimension along with activity details. For example, the following figure shows a specific user’s activity counter records from the context of the user form, one of which you’d have without the custom entity:
  
• Notice that the scoring logic in this approach is embedded in the workflow processes. In that sense it’s a little bit “hardwired”. With a little more work, you could create the ability for a user to configure settings for scoring, so that if you needed to change the score a user receives for an activity, you could update a record rather than the workflow process itself. One way to do this would be to create another custom entity, such as Activity Counter Settings, and have each activity counter record be a child record of a specific settings record. If you take another look at the way I created the activity counter record you’ll see a clue about how this approach can work:
  
  The Counter Setting field is a lookup, which if filled in will associate a counter record with a parent setting record. If you took this approach, then the Score field could be filled with dynamic values rather than directly as in this approach.

There are many flavors of round-robin record assignment processes, but they all share some fundamental properties. The most important is that they all implement what you might refer to as an “egalitarian” record assignment process. For example, records are assigned first to sales rep 1, then to sales rep 2, and so on until sales rep N gets her assignment, then the process starts over again with sales rep 1 next in line.

We’ll examine a dialog process version of this here, but since we’re on the topic it might be worth characterizing several different assignment processes, all of which could be implemented with workflows or dialogs in Dynamics CRM:

• If you create an opportunity record, you own it. Call this the “chew your own meat” school of record assignment.
• If an opportunity is created for a customer you own, you get the opportunity. This is the strong version of the owned-account school of record assignment.
• If an opportunity is created for an industry or product in which you have expertise, it gets assigned to you. Call this the strong version of the industry expertise school.

Many organizations combine several different styles of record assignment, within or across business units. For example, you might use a strong owned-account assignment approach for opportunities created for owned accounts, but have a set of accounts designated as “house accounts”, and assign opportunities for those accounts on a round-robin basis.

Or if you’re a mortgage banker, you might assign loan modifications on a round-robin basis. Since load modifications don’t have new money associated with them, you might put them in the take-one-for-the-team category and distribute them equally to a pool of loan modification processers.

Workflows v. Dialogs for Round-Robin Assignment

Remember our discussion comparing the data context of workflow and dialog processes. One implication of that discussion is that round-robin processes are much easier to implement with dialog processes than with workflows. This is because a running instance of a workflow doesn’t have any way of knowing anything about other instances, and thus doesn’t know anything about previous record assignments. The standard way of getting around this in a workflow is to create a custom entity that functions as the parent record of every opportunity needing to be assigned. (For example, Ben Vollmer wrote the first article on this topic.)

The workflow can then both query the parent record for things like which user got the last assignment, as well as update it with who’s getting the current assignment. As you will see here, this kind of workaround in unnecessary for dialogs, since they can create their own data context as they run.

The scenario for this example is as follows:

1. A user selects a specific opportunity record and starts the dialog process.
2. The dialog builds a query of “participating users”: that is, users designated as participating in the round-robin process.
3. The query will be in ascending date order by the date each participating user was last assigned an opportunity by the process.
4. The user will be instructed to select the user at the top of the list, but can depart from the “last-in first-out” rule if necessary.
5. After the user is selected, the dialog assigns the record and performs some other data updates.

Setting Up

This dialog requires customizations to the User entity: a check-box field to specify participating users, and a date field to keep track of the last assignment date:

The following figure shows how these fields could be placed on a user form:

Of course in a production environment you don’t want any old user going in and changing these things, so you’d need to come up with an approach for making sure that the only users who can change them are the ones that are supposed to be able to.

How it Works

For this example, let’s start by examining the user experience. To keep it simple, I’ll start from the opportunity data grid, but in a production environment you might start from a queue for unassigned opportunities, and lock down the queue so that only certain users can kick off the process. The following figure shows how it looks as a user runs the process: a single opportunity record is selected on the grid, and the dialog prompts to select the user to whom the record should be assigned:

The two most important things to notice about this are as follows:

• Only a subset of users are available for selection. You’ll see how the query uses the Participates in Round Robin Process field to filter out non-participating user records.
• The list of participating users is presented in ascending order by the Last Assignment Date field. Essentially, this prompts the user to apply the last-in-first-out logic, but allows for out of order selection. The user is instructed to provide an explanation for any out of order assignments in the text field.

Suppose I finish that dialog by selecting User A. The selected opportunity is removed from the My Opportunities view (unless I happen to be User A!) because the dialog process assigns it to that user. Now if I run it again, the experience is slightly different:

Now User B percolates to the top of the list. As you’ll see next, this is because the dialog process updates the Last Assignment Date field so you’ll always have the ability to sort by that field.

1. Building the Dialog Process

   The dialog itself (name) is created for the Opportunity entity, and is available to run only on demand. The following figure shows the step editor for the dialog process. I’ve used stages to organize the process in the designer, in what is a very common configuration for a dialog process that uses a query:

   1. Query. This stage contains the single Query step.
   2. Dialog UI. This stage presents the user experience; the first prompt uses the query to present the the list of participating users.
   3. Post-dialog Processing. After the user clicks Finish, the steps in this stage create records, assign them, update them as necessary and so forth.

   

   The next figure shows how to construct the Participating Users query. The single filter condition uses the custom field added to the user entity (Participates in Round Robin Process). To sort the query in ascending order by Last Assignment Date, click the Edit Columns button:

   

   The next figure shows how to construct the Prompt and Response using this query. I used the Prompt Text to instruct the user on what to do for out of order assignments, but if my advice got much longer than this, I’d probably use the Tip Text to give it a cleaner look. Also, notice how I constructed the Separator, using a semi-colon and some static text to make it more obvious what the date field refers to:

   

   The first step in stage 3 is pretty obvious: it assigns the selected record to the selected user. The second step is more interesting. This updates the Last Assignment Date field on the user record with the current time, so that next time you run the process the user with the most recent assignment goes to the bottom of the list:

   

   Some time ago I made a video on this kind of a dialog process. You can see it, along with a few others, on the Trick Bag Video page.

This site is a great resource and I recommend you use it. You can sign in with your Windows Live ID, and once in you can go directly to pages like this one: https://connect.microsoft.com/dynamicssuggestions/Feedback

My personal favorite of the top ten most requested new features is currently at the number two spot:

The ability to do “NOT” searches just seems like something the product should have. Customer tend to assume it’s there, and it’s difficult explaining to a customer why we can’t create an Advanced Find query showing which customers have not purchased product A, or which leads don’t have any activities created for them:

While you can do queries like that easily with SQL, you cannot use the Advanced Find UI to create them.

And eyes really start glazing over when you try explaining why you cannot build reports showing information like that in Dynamics CRM Online, while you can in an on-premise deployment:

Dynamics CRM Online can do SSRS reports now, bringing it closer to parity with the on-premise version. But you cannot use SQL in custom “SSRS” reports for Dynamics CRM Online; you must use FetchXML instead. And FetchXML cannot do NotExists (sub queries) or NotIn (queries)
like SQL can. (I guess we should really refer to them as FXMLRS reports!)

I’m always impressed with the quality of the feature requests on the Connect site; the Dynamics CRM suggestions in particular are full of things that, if added, would really save us working-class CRM consultants a lot of time.

Here’s a tip: for maximum impact, review the list before you post a suggestion to see if somebody else has already suggested it. Currently 30 votes gets a suggestion in the top ten, and my guess is a single top-ten suggestion is more likely to be added than if it’s actually hidden in three separate but similar suggestions each with 10 votes. For example, I was surprised that Pablo’s suggestion only had 8 votes:

Surely that’s a top ten or at least a top twenty suggestion! But then I noticed a few other suggestions that were close enough to siphon off some votes. Anyway, Pablo’s suggestion now has 9 votes, and I encourage you to get in there and make your voice heard.

In my company’s structure we have both business units and security roles. I am not sure if the question I am going to ask pertains to either of these but I thought I should give it a shot. When a person “shares” a parent record … let’s say an account with another individual inside or outside of their same business units does that mean all “child” records i.e. opportunities, contacts of that account are now visible to the person the account record was shared with?

Excellent question, Sara. I thought I must have written about that, so I searched the last two year’s worth of Trick Bag articles. I found lots of articles on many-to-many relationships, but not a single one on the more common one-to-many variety. So I thought I better write one.

While there is a business unit/security roles component in the answer to your question, it really has more to do with customizing the default one-to-many relationships than it does with security roles.

Default One-to-Many Relationships

Let’s start with how Dynamics CRM entity relationships work out of the box. I’ll use the account entity to illustrate, partly because it’s at the top of the relationship heap in CRM and has more child records than most other record types. For example, account has built-in 1:N relationships to contact, opportunity, email, task, appointment, and so forth. Generally speaking, the links you see in left navigation on a CRM form are entities the form entity has a 1:N relationship to.

The default behavior of all of the system 1:N relationships is what’s known as Parental. This means that anything you do to a parent record cascades down to all child records. A good way to understand this is to examine the scary dialog you see when you try to delete an account record:

In the parlance of 1:N relationships, we say that deleting the parent record “cascades down” to child records. It turns out that the other things you might do to a parent record — such as assigning and sharing it – also cascade down to all child records. So there’s the specific answer to your question about sharing: unless somebody’s customized your Dynamics CRM, when a parent record is shared all of its child records are shared as well.

Customizing 1:N Relationships

But that parental behavior can be customized. For example, if you open up the solution explorer (i.e., start customizing!) and drill down into the Account entity, you can click the 1:N Relationships tab and see something like the following figure:

I say “something like” since this is customized and might look a little different from yours. In particular, notice that in the figure the Contact and Opportunity relationships are set to Configurable Cascading. These are customized, away from their default Parental behavior. You can customize these by double-clicking on one of the rows to open its Relationship Definition dialog. The following figure shows what this looks like for the Account -> Contact 1:N relationship in my example:

Notice that the Type of Behavior is set to Configurable Cascading, and Share is set to Cascade None. That’s how I configured the relationship for opportunity as well. So in this scenario, if I shared an account record with another user, here’s what would happen:

• Appointments, tasks, e-mails would all be shared
• Contacts and opportunities would not be shared

This specific customization could account for child records not being shared along with the parent, which was one of the issues reported by Sara’s users.

There are four options in these “cascade” drop-downs:

When you make changes like this, after you publish customizations they take effect, so it’s a good idea not to do this in a production environment unless you’ve thoroughly tested first.

So that’s how you customize the behavior of the default 1:N relationships. And just remember it’s the relationships that are referred to as Parental that are the ones you want to customize. There are plenty of relationships that are described as System (I didn’t show any of these in the example above, but they’re there!), and the system relationships cannot be customized.

Sharing and Security Roles

What this has to do with security roles is that Share is a security privilege. The default security roles have pretty generous sharing privileges, as you can see from the following figure. Salesperson is one of the least generous security roles and even it has organization level sharing privilege.

You could customize this, for example by dialing the Share privilege on Account down to User-level (a yellow quarter pie-piece, obviously J ), and then users would only be able to share records they owned. But if they could share a record, the cascading behavior is determined by the customizable behavior of the 1:N relationship.

So I’ll go with the short version and emphasize the IN Dynamics CRM part. For a good overview discussion of marketing automation, visit the Wikipedia page for marketing automation.

Anyway, however you refer to it, in my view it’s the single most important category of Dynamics CRM add-on solutions.

In this article I’ll provide a mini-case study of my early experiences with ClickDimensions, which is one of the leading providers in the space and which I recently began using. If you’re new to the topic or new to Dynamics CRM, you might wonder why you’d need something like this at all. After all, Dynamics CRM has a marketing module – why can’t you just use the built-in features?

That’s a good question, and to answer it I’ll list the most important requirements that would cause a business to consider purchasing a marketing automation add-on to Dynamics CRM. You can think of this as a laundry list of “things you’d like to do in Dynamics CRM, that are not available in the base feature set, and that marketing automation add-ons can do”.

E-mail Tracking

This is probably the most important thing these add-ons provide that you don’t get out of the box in Dynamics CRM. This is a standard feature in standalone applications like Constant Contact: after sending an e-mail, you can see who opened it, who clicked through, which pages they clicked to, which e-mails were undeliverable and who wants to opt out, as well as the date and time all of these events happened. The obvious problem with standalone applications is … they’re standalone. Constant Contact does a great job with e-mail marketing, but it’s not a CRM and it’s not where your customer records live, so you have to spend a lot of tedious time exporting, importing and moving records back and forth. With e-mail tracking integrated in your CRM, you can send an e-mail and then see statistics like these:

Those are summary statistics, but even more important is what they’re a summary of: special activity records, stored in CRM and associated directly with your customer records. The following figure illustrates one of my favorite ClickDimension activity types, the Click. You can see they’re associated with contacts, we know what page they visited, the time they clicked and so forth:

This is the “big bang” of CRM-centric marketing automation: if you organization combines email marketing with direct sales follow up, providing your sales team with actionable information like this can improve your selling effectiveness more than any other single factor.

E-Mail Template Design

E-mail design is another feature gap addressed by marketing automation add-ons. Dynamics CRM does have an e-mail template editor…but it’s very limited and only supports very basic text editing capabilities. If you want to create really nice HTML templates and don’t want to write the HTML from scratch, you’ll need advanced template editing features, and this is a checklist item for CRM marketing automation add-ons. The ClickDimension template editor is rock-solid, and as you can see from the following figure, about as full-featured as you’re likely to have time for.

Analytics

I’ve been using various forms of marketing automation add-ons in CRM for several years, and when I first started, the analytics features were the ones I cared the least about. Basically, what these give you is the ability to track web site analytics – visits, page views, and the like. And just as with email tracking, the big advantage of having this inside CRM is the ability to track activities directly back to your lead and customer records. So while it’s true Google Analytics will outpoint any of these add-ons in a feature-walk, tying visits and views back to my contact records is not something Google does, nor is it something I’d want them doing!

Here’s a good example of the power of web analytics integrated in CRM: the following figure is a dashboard in my company’s production Dynamics CRM. Both charts are daily time series for the last 30 days of a custom ClickDimensions entity, Page Views. The top one is all page views, and is similar to what you might see in external analytics apps. But the bottom one is filtered to only show page views tied back to contact records. Notice the two spikes I’ve highlighted. Those are on the same days as the most recent two sends of my email newsletter. Once you see this, it’s obvious that you should expect to get a lot more non-anonymous page views immediately after an email blast goes out…but it’s nice to see that it actually happens that way!

E-mail Deliverability

This is a pretty specialized area, and the more emails you send, the more important it is. For lots of reasons – avoiding heavy load on your email server, getting tagged as a spammer and so forth – most email marketers prefer to outsource delivery to specialists. Here’s a link to the ClickDimensions page that describes their deliverability features.

In this area, ClickDimensions has a nice feature that plugs Spam Assassin directly into CRM. For example, the following figure shows the window that pops up when I send a test email for a campaign.

I’m not a Spam Assassin SME, but with some tweaking based on advice from ClickDimension’s support folks, I was able to get my Spam Score down to 2.5 from 4.5, and when it comes to your Spam Score, lower is better.

Internet Lead Capture Forms and Surveys

You might think that features like these are the marketing automation version of feature bloat, but once you start using one of these add-ons it turns out there are lots of benefits of going all-in. The basic idea is to track as much interaction as you can back to CRM leads, contacts and accounts. Filling out a form on your web site and responding to a survey are two important interaction channels, and if a marketing automation add-on provides these features you can track back responses much more easily than with the ala carte approach, using form capture, survey tools and the like from lots of different vendors, none of which track back to CRM records.

In my most recent e-mail newsletter, I included a link to a survey I built with the ClickDimensions survey designer which like all of their functionality is available within Dynamics CRM. I called it the Trick Bag Content Survey, and each question allowed a respondent to indicate their preference, on a 1-10 scale, for a topic area.

The following figures highlight several of the advantages of the CRM-centric approach of these marketing automation add-ons:

• Custom view for Survey Answers entity. ClickDimensions is installed as a Dynamics CRM 2011 managed solution, and several custom entities are included as solution components. One of these is the Survey Answers entity, highlighted in the figure. The entity is customizable, and you can see the custom view I created to include just the answers to the survey I deployed through my newsletter.
• Question responses scored and associated with customer records. The highlighted column includes enough of the contact field to demonstrate the power of the crm-centric approach: survey answers, submitted forms, e-mail responses, site visits, page views…these and other interactions can all be tied back to customer records.

And to assist in the visual display of this quantitative information (paraphrasing from http://www.edwardtufte.com/tufte/books_vdqi ) I created a custom chart:

Several Trick Bag readers have correctly emphasized the importance of avoiding gratuitous use of charts and dashboards in CRM. I think this chart is a good example of how visualization really can add value: there’s really no way from the grid alone to extract the information conveyed by the chart, and a report would be too much information.

And besides being the best way to present these survey results, the information communicated by the chart is actionable: I guess I better write more articles about workflows, charts and dashboards, and dialogs!

• If you want users to be able to search and select from a look up of all active records, you must use the Lookup response type approach.
• If you want to provide more structure to a look up and present users with pre-filtered or dynamically filtered lists to select from, you must use the Query CRM Data approach.

Querying CRM Data and CRM Data Relationships

Dialog Processes and Data Context