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;

    }

}

• 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.

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.

Dialog processes, unlike workflows, must be started and run through to completion by a user. The standard way to kick them off is to select a record on a grid, click the Start Dialog button on the ribbon, and then select the dialog you want to run.

That’s a fine approach to take, but sometimes there are better ways to go. For example, suppose you’ve got a process to walk a receptionist through a phone conversation, and part of the process is to look up and check whether the caller is from an existing client. Depending on how the conversation goes, the process might end up creating one or more related records…but you don’t know before-hand which records will be created. Since the caller might not be a customer, you can’t write the process for an account or contact, and it’s a little artificial to force the creation of a lead record first … just to start a dialog process!

In scenarios like the one I just described it turns out the user record type is often the best choice for the primary entity of the process. That in turn raises another problem, in that it’s a little odd to require a user to navigate to their user record to start a dialog process.

Fortunately there’s a better way to do it, and for dialogs written for the user entity, intended to be run by the current user, the tip I describe here is the way to go. The basic idea is to create a dashboard with an HTML web resource that contains a hyperlink to run the dialog process. The link has to be constructed dynamically using JScript, and although the code might seem a little tricky if you don’t have much experience with HTML or scripting, the good news is, it’s highly re-usable code since it’s essentially the same thing every time.

The end result is illustrated in the following figure. I’ve got a “Refer Lead” dialog process exposed as a link in the dashboard component on the left, and I’ve placed a list of the current user’s referred leads in the component immediately to the right:

When the user clicks Refer Lead, the dialog opens in a new window, and the user runs through it as usual:

The approach I describe here uses a general technique in Dynamics CRM referred to as URL-addressable forms. This is very useful and comes up in many different contexts. I covered some of its uses and how to do it in this article.

To get a feel for how URL-addressable forms apply to dialogs, follow these steps:

1. Run any dialog process and on the first page of the process press the Ctrl+N key combination, or press F11.
2. A new window opens, and the URL of the dialog process is exposed in the browser’s address bar.
3. Click the icon at the beginning of the URL, and drag and drop it onto your desktop.
4. Close the two open dialog windows and then double-click the shortcut on your desktop. Voila, the dialog runs correctly, and you’ve got a shortcut you can use any time you like.

If you examine the nasty-looking URL, you can pretty much see what’s going on: it starts with the URL of your CRM organization, adds some stuff to tell CRM it’s a dialog you want to run, then refers to the dialog by its GUID, then refers to the user by its (ok, his or her) GUID. Here’s what a URL like that looks like:

https://businessprocessesindynamicscrm.crm.dynamics.com/cs/dialog/rundialog.aspx?DialogId=8C5CE987-7653-4ADD-AF10-EC52147FF0DF&EntityName=systemuser&ObjectId=FC09123D-2A32-417A-BA08-5C76D99BEDF6

It’s actually useful to understand the different components that make up a URL like that, and I provided a detailed description of them in this article. Here’s a summary:

• https://businessprocessesindynamicscrm.crm.dynamics.com is the CRM organization URL.
• /cs/dialog/rundialog.aspx instructs CRM you want to run a dialog.
• ?DialogId=8C5CE987-7653-4ADD-AF10-EC52147FF0DF is a query string instructing CRM which dialog to run, identifying it by its GUID.
• &EntityName=systemuser&ObjectId=FC09123D-2A32-417A-BA08-5C76D99BEDF6 is another query string, this one specifying first the entity the dialog is written for, and then the GUID (”ObjectId”) of the record to run it for.

So that URL will always run the dialog, but it will always run it as you. That is, the GUID of the user (FC09123D-2A32-417A-BA08-5C76D99BEDF6, in this case) is hardwired. To generalize this and create the dashboard solution that always runs the dialog as the current user, you really have to do two things:

• Figure out how to create a web resource with a hyperlink that can open up a URL-addressable form in a new window.
• Figure out how to dynamically construct the user component of the URL. And while we’re at it, we might as well construct the organization URL dynamically too. That way, you can use the same basic code in any CRM organization.

Create the HTML Web Resource

The first step is to create the HTML web resource. Navigate to Customizations, click Web Resources and then click New. Give it a good name and select Web Page (HTML) for the Type. Click Save and you will see the URL fill in, like the following figure illustrates:

Once you’ve saved it you can click the Text Editor button, then click the Source tab and you should see the following:

Just kidding! (or jk, as Jack would say) You actually have to enter the code yourself – it doesn’t just appear there.

Here’s the code:

The first part – <SCRIPT src=”../../ClientGlobalContext.js.aspx”></SCRIPT> — is important because this HTML web resource is running from a dashboard. According to the Dynamics CRM SDK, “When you need context information outside a form, include a reference to the /webresources/ClientGlobalContext.js.aspx page in an HTML Web resource.“
Read more on ClientGlobalContext…

The second part – everything in the next <SCRIPT>…</SCRIPT> block – is a function contributed by my brilliant colleague Eric Reiner to open a window in a way Internet Explorer will considers safe. If you try to get this to work with a straight <A href=url>Click here</a> approach, it throws an error and just sits there.

The third part is the URL that gets passed to the safeNewWindow function. Notice there are two calls to functions included in GetGlobalContext: getServerURL() is how we can dynamically construct the CRM organization URL, and getUserId() returns the GUID of the current user.

Using this approach, the only thing that’s hardwired is the ?DialogId=1F7A557F-3927-41D4-AF8F-7282B62358DD part. That’s OK, though – since you’ll always know the dialog process you want to call (in this example, Refer Lead) it should be hardwired.

After creating your Web Page (HTML) web resource, be sure to publish it.

Create the Dashboard

The dashboard is the easy part. You can do this with either a personal dashboard or a system dashboard. To keep the steps to a minimum I used a personal dashboard in this example. Follow these steps:

1. On the site map, click Workplace and then click Dashboards.
2. Click New on the ribbon.
3. Select any of the dashboard layouts, and then provide a name and save the dashboard.
4. Select one of the dashboard components, and then click Web Resource.
5. Click the browse button and you should be able to select the Web Page HTML web resource created above. (Not all web resources can be placed on a dashboard, but HTML web resources can be). This can get a little busy, especially if you’ve got the Activity Feeds solution installed, but if you look around a little you can find your web resource. The following figure shows my Refer Lead web resource selected in the lookup:

   

Click OK a couple of times and you’re done.

Personal Dashboards or System Dashboards?

Now you might wonder why I went to all that trouble to make a dynamic link that will run a dialog as the current user… but then exposed it on a personal dashboard that nobody except ME will ever see. Good point. Let’s contrast personal and system dashboards to decide which one is the best approach:

• A personal dashboard can by default be created by any user, and can only be seen by the user that created it. Personal dashboards are user-owned, so they can be assigned to a user, a team, and they can be shared out to users or teams.
• A system dashboard is the opposite: it can only be created by a system administrator but when created it can be seen by everybody. System dashboards are organization owned, and are always visible to every user that can see any dashboards.

Effectively, what these differences mean is that personal dashboards can be targeted, but system dashboards cannot be. So if you want some users to see a dashboard but not all users, a personal dashboard is the way to go. After creating it, you can either assign it to a user or a team, or share it with as many users or teams as required. If it’s shared/assigned to a user, or to a team of which a user is a member, the experience will be the same as it is if you create a personal dashboard. It’s available in the My Dashboards section of the Dashboard drop-down menu:

Document Dialogs using the Description Field

Lots of record types have description fields, and dialog and workflow processes are no exception. With processes – and especially dialogs – the kind of information you use the description fields for is a little different than the typical notes you’d enter about a customer or opportunity record.

For example, I wouldn’t normally enter your GUID on the description field of your contact record, but I’d definitely enter the GUID (”Dialog Id” as it’s referred to in the url as we saw previously) of a dialog in the Description field on the Administration tab of the process designer:

I’m working with an on premise 2011 client. I’ve created one parent and three child BU’s. I have created three different forms for 4 entities and want the forms to be shown based on the security roles from the child BU’s, but whenever I go to assign them through the form I cannot see any roles but those of the parent. I feel I’m missing a step, but don’t know where I’ve gone wrong. Can you point me in the right direction?

Good question – I wondered about that myself the first time I noticed it!

The problem is, when you assign security roles for a custom form, the only available security roles are those from the root business unit! Since you cannot target forms directly to security roles for a child business unit, the best solution I’ve found so far is to create custom security roles in the root business unit, target the forms of interest to those security roles only, and then make sure that the folks in the business unit who need to see the custom version of the form have those security roles assigned to them.

The following figure shows two custom forms for the opportunity entity, East and West. (The organization has two child business units with the same names):

If you select one of the custom forms and click Assign Security Roles, at first you see this:

Notice there’s no way to select a child business unit. That’s the correct observation of the blog reader who asked the question. Suppose I create two custom security roles, “East Business Unit” and “West Business Unit”. A couple of points about these custom security roles:

• To serve the purpose we need them for here, they need to be in the root business unit, but I’ll name them that way to indicate what they’re for.
• They also do not need much in the way of privileges, and in particular I don’t want them to elevate anybody’s security privileges (or at least, not much!). I’ll create them by copying the Salesperson security role.

After doing that and opening up the Assign Security Roles for the form again, I’ll see the new security roles. Here I’ll assign the East Business Unit security role to the East version of the form:

And then, for the default version of the form (I changed the name from the bland “Information”), I’ll change the Display to option so it only displays for System Administrators:

We’re almost done, but not quite: how do we push that custom East Business Unit security role out to the users in the East business unit? Assuming everybody in the business unit should see the same version of the form, the easiest way to do it is by taking advantage of the default team for the business unit, and assigning the security role to it.

Default teams for business units are new in CRM 2011, and have several advantages for an application like the one we’re discussing here. In particular, since every user assigned to a business unit is automatically assigned to (and cannot be removed from) the business unit’s default team, we know that assigning the security role to the default team will push any of its privileges (including ones to custom forms as in this example) will work.

So, select the default team for the East business unit, and click Manage Roles. Then select the custom East Business Unit security role, click OK, and we’re done:

Now, all users in the East business unit will see the custom version of the form, and the other security roles they have will determine whether they can see other versions of the form.

Now there’s nothing wrong with that, and judging by how many times I was told by CRM 4.0 customers, “we need dashboards!”, the default settings – that all users can view and create charts and dashboards — will likely be fine for most organizations. However…they won’t be for all organizations, and recently I’ve had a few questions along these lines: “how can we configure it so some of our users can see the dashboards we want them to see, but not waste a lot of time creating charts and dashboards of their own”?

Background: System Charts and Dashboards v. Personal Charts and Dashboards

So…who can see Dynamics CRM 2011 charts and dashboards, and who can create them? These kinds of things are determined by the security roles assigned to a user, and in order to configure security roles for charts and dashboards, you need to understand the distinction between System charts and dashboards, and Personal charts and dashboards. The following table (valid for the default security roles) compares these along several different dimensions:

Let’s start with System charts and dashboards. As indicated in the table, most users cannot create these. These are considered system customizations, and once created they are by default visible to all users. So…it’s probably a good thing most users cannot create these things! The most obvious examples of these are the default dashboards you see in the Workplace, and charts like the Sales Pipeline chart exposed on those dashboards, as in the figure shown above.

Now on to Personal charts and dashboards. Notice in the previous figure the New button on the ribbon. If you click that you will be creating a Personal dashboard. It can be confusing at first keeping track of whether you’re creating a personal thing (chart or dashboard) or a system thing, so here’s my rule for how to remember the difference: if you click a New button on one of the application ribbons in Dynamics CRM 2011, the thing you’re creating is personal. You have to work harder to create a system thing, and again, since everybody will see it, that’s a good thing. The following two figures show, respectively, the default Dashboards ribbon every user sees when working with dashboards, and the default Chart tab for the opportunity data grid.

On the Dashboards ribbon, any user can click New to create a new personal dashboard.

On the Charts tab for most data grids, any user can click New Chart to create a new personal chart.

From a security standpoint, personal charts and dashboards behave the same way personal views do: while every user can create one, by default the only user who can see one is the one who created it. This can be a little confusing at first. For example, we’re used to thinking that a user with the System Administrator role can “see everything”, but that’s not true: they can only see almost everything. In fact, if you examine the System Administrator security role you will see they only have User-level Read privileges on entities such as Saved View, User Chart and User Dashboard. So unless a user shares a personal chart, nobody else can see it, not even a system administrator.

Locking Down Personal Charts and Dashboards

OK, so now we know there are two different types of charts and dashboards. How do we modify security so our sales reps don’t waste time goofing around creating charts and dashboards?

Well, we know they can’t create system charts or dashboards, so we only have to prevent them from creating the personal (or user) variety. Since I’m picking on salespeople here, I’ll use the Salesperson security role in the example:

1. Click Settings, and then click Administration.
2. Click Security Roles.
3. Select the Salesperson security role and double-click it to open the form.
4. On the Core Records tab, remove the Create and Read privileges (the first two columns) for the User Chart and User Dashboard entities:

The following figure shows the tool tip you see when you hover over one of those empty red circles in the security role UI. If you try this, you’ll notice that the only access levels the Create and Read privileges can have for those two entities are None, and User.

So, after customizing the security role, suppose I sign in as a user with the following characteristics:

• Only assigned one security role, the customized Salesperson role.
• Not a member of any teams.

Here’s what I will see when I navigate to Opportunities:

The Charts tab is absent from the ribbon, just as it will be from anywhere else it would usually appear. Similarly, the Save and New buttons will be removed from the Dashboards tab:

Locking Down System Dashboards

Now, suppose you not only don’t want them wasting time creating personal charts or dashboards, but you don’t even want them looking at system dashboards or charts. Security privileges can be used to prevent users from seeing these as well. For this, you need to customize the System Chart and System Form entities on a security role’s Customization tab:

By default, only the System Administrator and System Customizer security roles have Create privileges for these, but all security roles have Read privileges. Continuing our example, suppose you lock down the Salesperson role even more, by removing the Read privilege for System Chart and System Form as shown in the previous figure.

Then if you sign in as a user with only that security role, here’s what you would see if you navigated to dashboards:

If you navigate to the opportunity data grid, you will see that the user experience degrades in a slightly better way – instead of seeing a Not Available sign, you just don’t see the chart pane at all:

Role-Targeted Charts and Dashboards

So that’s how you can prevent a user from seeing any (system) charts or dashboards. But suppose instead of a completely locked down experience, you were going for more of a targeted one: salespeople see the dashboards they need, customer service reps see only the dashboards they need, and so on. How would you do that? This article’s long enough already, so I leave you with that as a question. I’ll write up at least one solution to that problem in a future article, but in the meantime, if you’ve got one, feel free to let me know about it!

• Installment #1: Introduction to Dialog Processes
• #2: Prompts and Responses in Dialogs
• #3: Actions and Conditions in Dialogs
• #4: Querying CRM Data in Dialogs
• #5 Calling Dialog Processes with a URL

Some of the highlights of today’s content:

• The importance of the response data type.
• A handy reference for commonly used option set fields on the case, account, contact, lead and opportunity entities.
• Tips on how to add value to your dialogs by using hyperlinks in Tip Text

Enjoy, and if you’ve got any killer examples or puzzling head-scratchers, please share them and help to improve the finished product!

Drilling Down on Prompts and Responses

Pages are really just containers for the Prompt/Response pairs of a dialog process; these are where the real work takes place, so in this section we will review them more thoroughly. When you are designing a dialog process and click Set Properties for a Prompt and Response action, you see the Define Prompt and Response dialog. Here is the first of the two Prompt/Response pairs from the previous example:

Statement Label is a required field, and as you saw previously, the value you enter in the Define Prompt and Response dialog is what appears in the Step Editor on the Description line for the Prompt and Response.

Prompt Text is also required. This is the text that instructs the user what to do. Depending on the business functionality, you may want to structure this as a question to be posed to a customer, or it may simply provide instructions for the user.

Tip Text is optional. Use it to provide additional instructions for your users. For example, in a “guided conversation” dialog, the prompt text might present the question a sales representative is instructed to ask the customer. The tip text in this case could provide internal guidance to the sales representative, such as what the goal of the question is, or some of your products/services that might be relevant to the question, or tips on how to engage the customer in conversation on the topic. Tip Text, as well as Prompt Text, can contain hyperlinks. You can really jazz up your dialogs with some creative linking, and we will cover that in more detail below.

Response Details are important, and although they are not required, it’s hard to imagine a scenario that would not require them! These are what allow the dialog process to do something with the information gathered from the user. The following table includes the possible response types:

The Data Type and Provide Values settings are important enough to warrant special treatment in the following two sections.

Response Details: Data Type

As indicated in the table, there are three possible values for Data Type property, which is available only for Response Type values of Single Line, Option Set (radio buttons), and Option Set (picklist).

This is important aspect of dialog design and can be confusing at first, so let’s drill down on it.

Let’s extend the Create Case for Account dialog to understand the importance of the Data Type property. Suppose in addition to filling in the Title and Customer fields on the new case, you also wanted to fill in the Case Origin field. This is a system-defined option set field available for the case entity, and by default has values of Phone, E-Mail and Web.

Suppose you add a new prompt/response pair to the dialog, click Set Properties, and configure them as shown in the next figure:

The selected Data Type here is Text, which is the default value. (This is one of those places in Dynamics CRM where once you save a value, it cannot be changed.) After saving and closing the Define Prompt and Response dialog, the Step Editor will look like this:

You might then click Set Properties, thinking you can use Dynamic Values to update the Case Origin field with the value selected by the user in the process. The problem is that the Case Origin field on the case entity is an option set field, which although it has a label (Phone, E-mail, Web), is actually defined as an integer field. In the dialog, this means that you cannot update the field value with the process value, since it’s the wrong data type. You can see this in the following figure, where the selected field is Case Origin, and in the Dynamic Values section, the Case Origin variable has been selected in the Local Values section of the Look for drop-down:

If you try this, you will notice that you cannot select anything to populate to the Case Origin field on the case form. This is the standard behavior for when data types don’t match.

Now what you might try at this point is to build conditional logic into your dialog to work around this, testing for the value the user selected for the Case Origin in the dialog, and hard-wiring the entry of the corresponding option set value for Case Origin on the form. Yuck.

We will cover this in more detail below, but for now, let’s look at the right way to get this done!

The key is the Response Data Type, which in this example needs to be an Integer in order to directly update the Case Origin field. You will need to delete the Prompt and Response line (since you cannot change the Data Type once it’s saved), and re-do it like this:

The two most important things to notice are:

1. The selected Data Type is Integer. This will allow you to update the Case Origin field on the case form with the value selected by the user as the dialog runs.
2. Notice the Value of the Phone Response Value is 1. This must match up to the value stored by Dynamics CRM for that option set on the form.

Finally, after doing this, you can click Set Properties on the Create Case step of the dialog. The following figure illustrates that – once the correct data type is defined for the Case Origin dialog field – you can in fact directly update the Case Origin field on the case form. That’s what the “Response Option Set Value” field is for:

Tip: Commonly Used Option Set Values

The Dynamics CRM 2011 SDK contains a complete list of option set values for all system option set fields in the product…but that’s about as helpful as saying the dictionary contains a complete list of all the words in the English language! Like so many things, this issue – matching prompt/response values in a dialog to option set values for a Dynamics CRM field – has an 80/20 rule: most of your needs will be satisfied by a small number of the available options. In that spirit, this section includes the most frequently encountered option set fields from what we might refer to as the big five customizable entities in Dynamics CRM 2011. Since we’ve been discussing the Case entity, we start with that one, and then proceed alphabetically with Account, Contact, Lead and Opportunity.

1. Commonly Used Option Set Fields for the Case Entity
   

   Option Set Field Label (Schema Name)	Default Label	Corresponding Value
   Case Origin (caseorigincode)	Phone	1
   	E-mail	2
   	Web	3
   Case Type (casetypecode)	Question	1
   	Problem	2
   	Request	3
   Satisfaction (customersatisfactioncode)	Very Satisfied	5
   	Satisfied	4
   	Neutral	3
   	Dissatisfied	2
   	Very Dissatisfied	1
   Priority (prioritycode)	High	1
   	Medium	2
   	Low	3
   Service Level (contractservicelevelcode)	Gold	1
   	Silver	2
   	Bronze	3

    

2. Commonly Used Option Set Fields for Account
   

   Option Set Field Label (Schema Name)	Default Label	Corresponding Value
   Address Type (address1_addresstypecode)	Bill To	1
   	Ship To	2
   	Primary	3
   	Other	4
   Shipping Method (address1_shippingmethodcode)	Airborne	1
   	DHL	2
   	FedEx	3
   	UPS	4
   	Postal Mail	5
   	Full Load	6
   	Will Call	7
   Freight Terms (address1_freighttermscode)	FOB	1
   	No Charge	2
   Industry (industrycode)	Accounting	1
   	…	…
   	Wholesale	33
   Ownership (ownershipcode)	Public	1
   	Private	2
   	Subsidiary	3
   	Other	4
   Relationship Type (customertypecode)	Competitor	1
   	Consultant	2
   	Customer	3
   	Investor	4
   	Partner	5
   	Influencer	6
   	Press	7
   	Prospect	8
   	Reseller	9
   	Supplier	10
   	Vendor	11
   	Other	12
   Category (accountcategorycode)	Preferred Customer	1
   	Standard	2

    

3. Commonly Used Option Set Fields for Contact
   

   Option Set Field Label (Schema Name)	Default Label	Corresponding Value
   Address Type	Same as Account
   Shipping Method	Same as Account
   Freight Terms	Same as Account
   Role (accountrolecode)	Decision Maker	1
   	Employee	2
   	Influencer	3
   Gender (gendercode)	Male	1
   	Female	2
   Marital Status (familystatuscode)	Single	1
   	Married	2
   	Divorced	3
   	Widowed	4
   Category (accountcategorycode)	Preferred Customer	1
   	Standard	2
   Contact Method (preferredcontactmethodcode)	Same as Account

    

4. Commonly Used Option Set Fields for Lead
   

   Option Set Field Label (Schema Name)	Default Label	Corresponding Value
   Lead Source (leadsourcecode)	Advertisement	1
   	Employee Referral	2
   	External Referral	3
   	Partner	4
   	Public Relations	5
   	Seminar	6
   	Trade Show	7
   	Web	8
   	Word of Mouth	9
   	Other	10
   Rating (leadratingcode)	Hot	1
   	Warm	2
   	Cold	3
   Industry (industryscode)	Same as Account
   Contact Method (preferredcontactmethodcode)	Same as Account

    

5. Commonly Used Option Set Fields for Opportunity
   

   Option Set Field Label (Schema Name)	Default Label	Corresponding Value
   Revenue (isrevenuesystemcalculated)	System Calculated	1
   	User Provided	0
   Rating (opportunityratingcode)	Hot	1
   	Warm	2
   	Cold	3

    

   Response Details: Provide Values

   The other important option to understand when collecting response from users is whether to enter values manually as you design the process, or to get them from a CRM query. This is an important and potentially complex topic, and we will cover it in detail later in the book. For now, consider the following figure:

   

   In the previous examples, the Define Values option was selected, which means you simply enter the values yourself. Here, the Query CRM data option is selected. This is a super-important capability of dialog processes in Dynamics CRM 2011, as it lets you build prompts based on CRM data…so as the underlying data change, your dialog processes dynamically reflect the changing information.

   In the previous figure, the Query Variable “Practices Query” has already been defined. Query variables must always be defined before they can be used (makes sense when you think about it, right?), and in the Step Editor it might look like this:

   

   In this example, “Practices” is a custom entity my organization uses to track our different professional practice areas (e.g., CRM, Messaging…). If we want to associate a case record with a specific practice, the ability to build a query and populate a Prompt option set with all of our practices provides that ability.

   Again, more details on this later, but it’s important to know at this point that you won’t always have to enter all of the possible option set values manually as you design the dialog process!

   Tip: Use of Hyperlinks in Prompt Text and Tip Text.
   

   Notice that both of these have a button you can use to enter a hyperlink. This gives you a way to use external web content to support your dialog processes, and the general rule is: as long as a user can get to the content, you can use it. For example, suppose you enter the following text to the Tip Text in the Create Case for Account dialog:

   

   You can then position the cursor just after the “cases:” text, and click the
   Insert Hyperlink button to get the Insert Hyperlink dialog:

   

   The Text to display field is the link text the user will be able to click, and the URL is where they will navigate to. For example, you might enter the following values:

   

   After clicking OK and returning to the Define Prompt and Response dialog, you will see the following in the Tip Text:

   

   And after saving and activating the dialog, the user experience would appear like the following figure:

   

   When a user clicks the link, the referenced URL will open in a new window. This gives you the ability to extend dialog processes in lots of interesting ways, including:

• Linking to special offer pages on a web site for a campaign follow-up dialog.
• Linking to Dynamics CRM forms using the “URL-addressable” forms technique that allows any record for any entity to be navigated to with its unique URL. For example, if you use the product catalog, a specific product form could be opened with a URL like this one:

https://<yourorganizationhere>/main.aspx?etc=1024&extraqs=%3f_gridType%3d1024%26etc%3d1024%26id%3d%257bCBAC3403-1C74-E011-8947-1CC1DEE8DAD5%257d%26rskey%3d37636470&pagetype=entityrecord

• Linking to a Microsoft or other Internet page for documentation, supplemental training materials and so forth. This is essentially the example shown above.
• Linking to a Web Resource HTML page contained in a Dynamics CRM 2011 solution.

Use your imagination and creativity, but be aware of the following caveats:

• Hyperlinks in dialogs cannot be created dynamically in the current release.
• Users must have permissions to view the hyperlink, and since the hyperlink is external to Dynamics CRM, it would be easy to include a link some users could access and others could not. For example, permissions in SharePoint and Dynamics CRM are managed separately, so you cannot assume that any user with permissions in CRM to run a dialog process will have access to a SharePoint URL you provide as a hyperlink.

• Business Units
  • Names can be changed.
  • Can change the name of the root business unit to something other than the name of the organization.
  • Can delete business units in CRM 2011. To delete a business unit, you must remove all users, remove all teams, and then disable the business unit. Then it can be deleted.
• Users and Teams
  
  • In CRM 2011, both are full security principles – i.e., records can be assigned to both users and teams.
  • Users must always be assigned to a business unit, and they can only be assigned to a single business unit at a time.
  • Teams must be assigned to a business unit also, but the teams you create can include members (users, that is) from any business unit.
  • Teams, just like users, can be assigned security roles.
  • When users are added as members of a team, they keep all security privileges included in any of the security roles they’ve been assigned, plus they inherit all of the privileges from the team’s security roles. Since security roles are “additive”, this means that adding a user to a team will never give them less privileges and may give them more.
• Default business unit teams are created by the system when a business unit is created. These teams behave differently in some important respects from regular teams. Default business unit teams:
  • Cannot be deleted.
  • Cannot have their names changed.
  • Cannot have members not in the business unit.
  • Automatically assign membership to every user assigned to the business unit; cannot have their membership changed apart from changing a user’s business unit.

In my experience, the one thing that definitely doesn’t work is to simply let your users explore until they find the reports they need! If you’re responsible for customizing or configuring Dynamics CRM, you will generally need to take some steps to push the right reports out to the people who need them, and in CRM 2011, dashboards give you a great way of doing that. For example, take the built-in Activities report. It presents a stacked column chart, grouped by users, with segments of each column representing counts of the various activity types performed by users:

Rather than force users to locate it in the list of reports, you can give it more prominence by exposing it on a dashboard. For example, I’ve customized my organization’s dashboards to include one called “Activities: all Users, Last 90 Days”, and as a system dashboard it’s selectable from the Dashboards drop-down list:

Placing a Report on a Dashboard

You can’t place a report directly on a dashboard, however. In Dynamics CRM 2011, dashboards are really just specialized web pages designed to expose four kinds of “components”: Charts, Lists, Web Resources, and Iframes. The trick to placing a report on a dashboard is to remember that reports – along with all other views and forms – have unique URLs that can be used for direct navigation, or as the URL property of an Iframe control on a dashboard.

To create a dashboard that exposes the Activities report, follow these steps, using the web client:

1. Click Workplace, and then click Reports.
2. Locate the Activities report. The default filter is set to include activities for the last 14 days, so optionally, click Edit Default Filter and change the Last X Days filter to whatever you’d like, then click Save Default Filter.
3. Click Run Report. After a few seconds, the report will appear in the SQL Server Reporting Services (SSRS) Report Viewer.
4. Press the Ctrl+N key combination to open a new window with the URL/address field exposed, and click inside the field:

   

    

5. After making sure the entire URL is selected, use Ctrl+C to get it on the clipboard, and then close out of the two report viewer windows.
6. Create a new dashboard, give it an appropriate name, and delete all of the components except for one, and use the Increase Height and Increase Width buttons to make it big, along these lines:

   

    

7. Insert an Iframe control, and in the URL field, use Ctrl+V to paste in the URL on the clipboard:

   

    

8. Save & Close twice, publish your new dashboard and you’re good to go.

A couple of important points about that gnarly-looking URL:

• Note the “?action=run” bit after “viewer.aspx”. This is what will cause the report to open up directly in the viewer, bypassing the filter window you’ll get if you simply point to the report in the report grid and use the built-in Copy a Link command. (And if you ever see ?action=filter in the URL and want to open the viewer directly, just replace it with ?action=run.)
• The stuff to the right of “&id=%7b” is the GUID – the id that uniquely identifies records in Dynamics CRM, in this case the Activities report. Using Jscript to dynamically construct a URL that incorporates a record’s GUID is the key to many a Dynamics CRM mashup, so in case you haven’t seen this before, here’s a tip: the GUID itself is bracketed by “%7b” in front and “%7d” at the end; in my example, this portion of the URL looks like this: ?id=%7b6F7A3F7C-041F-E011-86DF-1CC1DE799302%7d – so the actual GUID is 6F7A3F7C-041F-E011-86DF-1CC1DE799302. As an example of when this is important, here’s a snippet of JScript that constructs a URL for a contact record:

   

  var serverurl = Xrm.Page.context.getServerUrl();
  

  var recordurl = serverurl+”main.aspx?etn=contact&id=”;
  

  var strtemp = contactid.replace(”{”, “%7b”);
  

  var strtemp = strtemp.replace(”}”, “%7d”);
  

  recordurl += strtemp;
  

  recordurl += “&pagetype=entityrecord”;
  

At the end of that bit of code, the recordurl variable will contain a nicely defined URL, suitable for inclusion in a workflow-generated email for example, for a contact record from my CRM. So just remember: if you’re one of my contacts, you’re a lot more than just a number: for example, you’re a GUID. Become a Dynamics CRM Trick Bag subscriber, and in addition to getting your very own GUID, I’ll send you my monthly e-mail newsletter, Dynamics CRM News You Can Use.
In the meantime, here’s a recorded segment from a recent training session I gave that demonstrates how to do this: