400 followers on Twitter. Whee! (And thank you.)

And, courtesy of CoreMotives web analytics, I can see that Trick Bag total page views for this 26^th week of 2011 have hit an all-time high, and the week isn’t even over yet.

Now here’s a dashboard!

How well I remember wondering why in the heck CoreMotives emphasized web analytics integrated in CRM so much the first time I saw a demo of their product. I think I kept interrupting Rhett Thompson, telling him to talk about e-mail marketing. Now, when I talk to people about CoreMotives, I always emphasize web analytics, and in the back of my mind, I’m thinking they probably want I should talk about e-mail marketing.

• 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

• Dialogs and Workflows Compared
• Dialog Properties
• Basic Constructs: Pages, and Prompt and Response Pairs
• Creating a New Dialog, Step by Step

The book will be available for purchase on Lulu sometime in July, and I’ll get more information up shortly on packaging, pricing and so forth. In the meantime, I hope you like it. It’s not edited yet, so please provide feedback and help me improve the finished product. With the addition of Dialogs, it’s definitely a far longer book I write than I have ever written, so I want to make it a good one.

Dialogs and Workflows Compared

In Microsoft Dynamics CRM 2011, Workflows are quite similar to their slightly less evolved CRM 4.0 ancestors. But the tools you have to automate business processes are significantly improved compared to the previous version, thanks to the introduction of the new Dialog process. Semantically, workflows and dialogs are each considered a type of Business Process. While both dialogs and workflows allow you to automate business processes, in many ways they function quite differently:

1. Table 1: Differences Between Dialogs and Workflows
   

   Dialogs	Workflows
   Present a wizard-like UI, and always require user input to start and run to completion	Always run in the background, and do not support user input
   Always run synchronously	Always run asynchronously
   Cannot be triggered automatically; must be started by a user	Can be started by a user, or triggered automatically
   Can query CRM data	Cannot query CRM data
   Can call child dialogs and pass information to them	Can call child workflows but cannot pass information
   Can be run on one record at a time	Can be run on multiple records

   Basically, what dialogs provide is the ability to create wizard-style processes inside Dynamics CRM, and with all the same great data awareness available in workflows. Think of dialogs as adding an information-gathering UI on top of the traditional workflow foundation: now, in addition to automating processes in the background, you can inform those processes with information collected from users in real time. Here are a few examples of what you can do with dialog processes:

• Create guided selling or service processes, with a series of questions guiding representatives through otherwise complex sales/service processes.
• Create wizard-style substitutes for traditional forms-based record creation.
• Create your own customized replacements for lead conversion, case resolution, or any other process where information on one record functions as input for the creation of another.

Dialog Properties

Primarily because they cannot be triggered automatically, dialogs do not have much in the way of properties. Here is the Process Properties section of the designer for a dialog called “Dynamics CRM Upgrade Conversation”, for example:

• Activate As

  Select Process if you want to activate the dialog for users to use; select Process Template if it is to be used as a template to create other dialogs.

• Available to Run

  Normally you will select As an on-demand process. This simply means that the dialog will be available to run when a record of the type the dialog is written for (Contact in the previous figure) is either selected on a data grid, or when a form is opened.

  Dialogs can call child dialogs, and that’s what the As a child process option is for. The two options in this case are:

1. If only As a child process is selected, then the dialog will not display on the ribbon for a user to run it; in this case it can only be called by a parent dialog.

2. If both As an on-demand process and As a child process are selected, the dialog will be able to call itself recursively. A common use of this technique is to create a “looping” process. For example, a dialog might walk you through the process of creating a case record for an account, and after gathering information and creating the case, ask you if you’d like to create another record. If you respond yes, the dialog calls itself as a child process and walks through another case create dialog.

Basic Constructs: Pages, and Prompt/Response Pairs

Dynamics CRM 2011 dialog processes contain one or more pages, which provide the visual experience for the user. Each page can contain multiple sets of prompts and responses. Prompts and responses always go together, so I often refer to them as prompt/response pairs. Pages, and prompt/response pairs, are the most fundamental difference between workflow and dialog processes: they present the user interface and gather the information that the rest of the dialog process can use to do whatever it needs to do.

One way to appreciate the fundamental rules presented in Table 1 is to consider the following rule:

Dialogs must contain at least one page, and at least one prompt/response pair.

For example, you can create a new dialog without any pages or prompt/response pairs, and you can save it. But if you try to activate a dialog like that, you will see the following scary dialog with a very clear message:  

Let’s walk through an example to illustrate these basic dialog constructs. The following figure shows the experience of the user running a dialog. Dialog pages are displayed one at a time, just like steps in a wizard. The page shown here has two prompt/response pairs, with the second one selected. Notice the Tip on the right side of the form.

The following figure shows the same dialog, but this time in the design environment:

Here you see the design environment, with the Process Properties section collapsed immediately above the Step Editor. This will be familiar to anybody with CRM 4.0 workflow experience – about the only obvious difference is that wherever in CRM 4.0 the word workflow would have appeared you now see process.

But as you will see, when you start designing your first dialog process and click the Add Step drop-down list, there are lots of new actions you will not recognize from your workflow experience! Let’s go through the process now of creating a simple dialog to start learning how they work.

Creating a New Dialog Process

In this exercise you will create a simple dialog to create a case record. The dialog process will be written for the Account entity, with the goal of simplifying the process of creating a new case record for an account that already exists in your Dynamics CRM. This kind of dialog process is in the category described above as “wizard-style substitutes for traditional forms-based record creation”. Note: unless otherwise noted, all of the step by step procedures in this chapter assume you are using the Dynamics CRM 2011 web client and have the System Administrator security role.

Step by Step: Create a New Dialog

1. Click Settings on the site map, and then click Processes in the Process Center section.
2. Immediately above the Processes grid, click New.
3. In the Create Process dialog, provide the following information:
   1. In the Process Name field, type Create Case for Account.
   2. In the Entity drop-down, select Account.
   3. In the Category drop-down, select Dialog.
   4. In the Type section, select the New blank process option.

   

    

4. Click OK. The Process Design form opens.

   

Your new dialog has been created, although of course it will not do anything yet. Again, a comparison with workflow processes will help to sharpen your understanding:

• For example, notice that unlike the workflow process designer, there is no Options for Automatic Workflows section. As mentioned previously, this is because dialogs must be started by a user.
• Also, notice that the As an on-demand process option is selected by default. If you de-select that option, and save and close the dialog…you will notice when you open it again that it’s been selected again. This is because if you haven’t selected the As a child process option, a dialog must be available as an on-demand process. We will come back to this point a little bit later!

Now let’s make the dialog do something. The next exercise picks up where the previous one left off, and illustrates how to add the basic Page and Prompt/Response components.

Step by Step: Adding Pages, Prompts and Responses

1. In the Step Editor, click the line that says “Select this row and click Add Step“.
2. Click the Add Step drop-down, and select Page. A Page component will be added.

   

    

3. With the cursor on the highlighted “Select this row and click Add Step” line, click the Add Step drop-down, and this time select Prompt and Response.

   

    

4. Click Set Properties. The Define Prompt and Response dialog appears. Provide the following information:
   1. In the Statement Label field, type Case Title.
   2. In the Prompt Text field, type Enter a title for the case.
   3. In the Response Type drop-down, select Single Line.

   

5. After entering the information, click Save and Close. The dialog closes and you return to the Step Editor. Notice that the text you entered in the Prompt Text field is automatically added in the Description field for the step. You can change it in either the Define Prompt and Response dialog or the Step Editor.
6. Click Add Step, and select Prompt and Response again. This time, provide the following information in the Define Prompt and Response dialog:
   1. In the Statement Label field, type Case Description.
   2. In the Prompt Text field, type Enter a description for the case.
   3. In the Response Type drop-down, select Multiple Lines (Text Only).
7. Click Save and Close. You will return to the Step Editor, which should look like this:

   

At this point, you could save the dialog, activate it, and run it. It would run, and you could see how the Page and Prompt and Response components combine to provide the user interface for the dialog…but it still wouldn’t create a case record, so let’s do one more exercise, picking up where we left off, to finish off and add that functionality.

Step by Step: Creating a Record with Information Gathered in a Dialog Process

1. Click on the Page step, and click inside the text box, where it says “Type a description here”.
2. Type Gather basic information.
3. Make sure the Page step is still selected (the entire Page block should be highlighted in blue), then click Add Step and select Create Record.
4. Click the drop-down to the right of Create and select Case.

   

5. Click Set Properties. The Process form editor opens.
6. With the cursor in the Title field, click the Look for drop-down in the Dynamic Values section of the Form Assistant, and select Case Title in the Local Values section of the list.
7. Click the Add button in the Dynamic Values section.

   

    

8. Click OK. The Title field is populated with Response Text(Case Title), which when the dialog runs will contain the text the user entered when prompted for Case Title.

   

    

9. Click inside the Customer field. In the Look for drop-down, select Account, which is the primary entity for the dialog process. Notice that Account is automatically populated to the second drop-down list. Remember we are selecting a value for the Customer lookup field on the Case form, and the only values that can be entered are account or contact lookups.
10. Click the Add button.

    

     

11. Click OK. The Customer field is populated with Account(Account). This is process design notation for “the account field (from the account entity)”.
12. Click inside the Description field. In the Look for drop-down, select Case Description in the Local Values section, and then click Add.
13. Click OK. The Description field is populated with Response Text(Case Description), and the Process form editor should look like this:

    

     

14. Click Save and Close to return to the Step Editor.
15. Click inside the Create action’s Description field, and type New Case.

    

     

16. Click Save and Close, to return to the Processes grid. With the Create Case for Account dialog selected, click Activate.

    

17. In the Process Activate Confirmation dialog, click OK, and your new dialog is ready to run!

Dynamics CRM 2011 has lots of important new feature, and the most visually obvious one is probably visualizations: the general term for the charts, dashboards and other ways of graphically representing the information in your CRM database. In this article I’ll start by providing a brief survey of the primary visualization techniques in Dynamics CRM 2011. Following that, I’ll drill down on what is probably the least obvious of these approaches, but potentially one of the most useful.

Survey of CRM 2011 Visualization Techniques

I count four main approaches to visualizing CRM 2011 information. The only caveat here is that these are all out of the box techniques, that is: things you don’t have to pay extra money for! Judging by the large number of BI/Analytics vendors exhibiting CRM 2011 add-ons at the recent Convergence show, there are plenty of additional techniques if your requirements outstrip what the core feature-set can provide. For now, though, let’s stick to the out of the box features and see how far they get us.

Approach #1: Inline Visualization

This is probably the most obvious one, since you can see it whenever you navigate to a Dynamics CRM 2011 data grid. For example, navigate to opportunities, expand the Chart Pane to the right of the grid, and select from any of the available charts for a graphical version of the data in the currently selected view. Here’s what these look like:

Approach #2: Reports

While you might think of reports as primarily non-graphical, that’s not really correct. Even the Dynamics CRM 2011 Report Wizard allows you to create charts for aggregated data, and if you can branch out a little and use SQL Server Reporting Services, you can go flat-out chart crazy. And by default, reports created with the Report Wizard are available from forms of the record type the report is created for, and will automatically use the current record as a filter for the report. In my opinion, this is a great feature and one that isn’t used as much as it should be. For example, I wrote a custom report, “Account Revenue History”, which displays a column chart of booked opportunity revenue, grouped by account. By default, it’s available on the Run Report menu from the account form, and it will filter the report by the current record:

Approach #3: Dashboards

If you’re the inquisitive type and you’ve had any experience with CRM 2011, you’ve probably seen these, since they’re pretty hard to avoid! (If you haven’t yet, click Workplace and then Dashboards.) Dynamics CRM 2011 dashboards are forms, and in fact they’re the first forms we’ve seen in Dynamics CRM that are not tightly bound to data the way account, contact and opportunity forms are. Dashboards contain components, which can include charts but also a few other things such as Lists, Web Resources and IFrames. Dynamics CRM 4.0 gave users the ability to create personal dashboards, but as I pointed out in an article about that, the users who need dashboards the most are the users least likely to want to create them. So one big win in CRM 2011 is the ability to create System Dashboards that can be centrally deployed and pushed out to whoever needs to see them.

Here’s a custom dashboard I use a lot. It’s based on information from some custom entities supplied by CoreMotives, an add-on I use for email marketing and analytics. I’ve got CoreMotives-supplied tracking code hooked up on the Trick Bag, so, right within my production CRM 2011 I can track web analytics like page views, tie them back to lead or contact records and all manner of cool stuff. But this article’s about visualizations, so here’s my Web Content Trends dashboard:

Approach #4: Record-Centric Dashboards

While it’s true that dashboards are forms, it’s also true forms can be turned into dashboards. I’m not crazy about the term I came up with to describe them, but I definitely like the functionality, which is what the rest of this article describes and shows you how to do. The following figure shows a customized version of the account form, displaying information from related records (opportunities, in this example) in a dashboard format. In the next section I’ll describe how to build a record-centric dashboard like this:

Record-Centric Dashboards

Imagine navigating to an account record, opening its form, and seeing a collection of charts and other visualizations with information associated to the account: sales history and forecast, service cases, activities and the like. That’s what I mean by the term record-centric dashboard, and while it applies equally well to any record type, I’ll illustrate it here with accounts. The approach I take utilizes an important new feature in Dynamics CRM 2011: the ability to create multiple forms per entity.

If you’ve seen demonstrations of this, chances are they were for what’s being referred to as “role-tailored forms”. This term generally refers to creating customized data entry experiences, appropriate to different users’ roles. For example, executives and outside sales reps might need a simple version of an opportunity form to enter the basic information about a sales opportunity; analysts and inside sales reps might need a more complex version of the opportunity form to back-fill the important details the heavy-hitters don’t have time for.

In scenarios like this one, different versions of the opportunity form will be assigned to different security roles. Users assigned to those security roles will only see the form appropriate to their role.

Record-centric dashboards, on the other hand, use forms for an altogether different function: rather than data entry, it uses forms for data display. In this scenario, a single version of the account form will be used by everybody in the organization with permissions to add or edit account records. A second version of the form will be available but won’t be used for any data entry: this will be our dashboard form.

There’s another new CRM 2011 feature that will come in handy here: Sub-Grids. The more I use these the more I like them. The most common use of sub-grids is to display a data grid of child records related to a parent record (e.g., on the account form display a sub-grid of related opportunity records.) But for the dashboard scenario, we’ll use the ability of a Sub-Grid to display a chart that visually depicts aggregates for the child records, rather than the records themselves.

Here’s how to create a record-centric dashboard like the one I showed in the previous figure. I’ll break it down into __ main parts:

Part 1: create a new form for the account record type to serve as the dashboard form:

1. Navigate to the accounts data grid, click the Customize tab, and then click Customize Entity.
2. Click Forms, and then click the first form in the list with a Form Type of Main. Double-click it to open it,
3. Click Save As on the ribbon, type “Dashboard” in the Name field, and then click OK.
4. You’re now editing the new Dashboard form. Remove everything from the form except for the Account Name field.

    

   Hint: The quickest way to do this is to select each of the tabs in turn, starting with the Details tab, and click Remove on the ribbon. The default account form has five tabs: General, Details, Contacts, Notes & Activities, and Preferences. The Details, Contacts, and Notes & Activities tabs can all be removed. By default the Preferences tab has the Owner field on it. It’s a required field, so move it to the General tab first and then remove Preferences. Then, remove the Description, Shipping Information, and Address sections from the General tab. Finally, from the Account Information section on the General tab, remove all fields except for the required ones (by default, Account Name and Owner). When finished, your “dashboard” form should look like this, in the Form Editor. Notice I’ve removed everything from the Header section also:

   

    

   To see an even more dramatically empty form, preview it. Here’s the entire form before you add anything to it:

   

    

    

Part 2: Add the Dashboard components:

1. Go back into the form editor if necessary, make sure Body is selected on the ribbon, and click the Insert tab.
2. In the Tab section, click One Column to insert a one-column tab. Double-click the tab to open the Tab Properties dialog, and enter Sales in the Label field. Accept the rest of the defaults so it looks like this:

   

    

   Then click OK.

    

3. By default, when you insert a tab, the system inserts a section, which you need to contain fields, controls and so forth. If you look, you’ll notice that the default section has two columns. Double-click inside the Section area to open the Section Properties dialog, and then click the Formatting tab on the dialog.

    

4. On the Formatting tab, select the Four columns option. This may come down to taste in form design, but I like the four column option since it provides the most flexibility in the layout options for the components of the dashboard. And when it comes to dashboards, you generally want lots of flexibility when it comes to layout options for dashboard components. Here’s what it should look like, just before you click the OK button:

    

   

    

5. If you want to add more tabs, feel free, but my articles are generally too long anyway, so I’ll just do one tab for now and you can generalize it from there!

Part 3: Add Sub-Grids to display the dashboard’s charts:

1. Make sure you’re inside the Sales tab, click the Insert tab on the ribbon, and then click Sub-Grid.
2. You’ll see the List or Chart Properties dialog. As you can see from the following figure, there are a lot of properties you can tweak. Here are the Display properties I used in this example:

   

   Here are a couple of the most important points about these properties:

• The chart – Actual Revenue by Month – is a custom chart I created, since the system charts didn’t quite have what I wanted.
• Notice I’ve selected the Show Chart Only option, and de-selected Display Chart Selection. I was going for a controlled presentation so users would not be able to do things like select charts that might not “work” in this context.

1. Click on the Formatting tab. Again, since controlling the presentation is important for dashboards, properties like these can take some experimenting to get right. The chart I’m currently configuring is going to end up in the upper-right part of the tab, it will span the second two columns and have sixteen rows.

   

    

2. Click OK to close out of the dialog.

    

After that I added two more components to my account dashboard; the process is similar to what I just showed, and for each one I needed to create a custom chart.

Part 4: Modify the Form Properties and Navigation and Assign Security Roles

Let’s take a look at the finished product again for reference. After I get everything just right and publish the entity, I can effectively toggle back and forth between the out of the box Information form and the new Dashboard form. Here’s the standard form:

Then use the Form Selector, shown in the following figure, to select the Dashboard version of the form:

Here are a few of the finishing touches I did in the form editor to get it as close as I could:

• Notice I removed all of the links in the Common, Marketing and Processes sections in left navigation. You can actually remove navigation entirely. That’s what I wanted to do since it would free up all of that space for the dashboard. The problem with that is…then you cannot access the form selector, so you wouldn’t be able to toggle back and forth between the forms! There’s probably a work-around for this. Let me know if you come up with one!
• When you create a custom form the way I showed above, by default it’s only available to users with the System Administrator and System Customizer roles. Since the purpose of this little exercise was to create a dashboard form that would be available to everybody, I needed to click the Assign Security Roles button in the form editor, and select the Display to Everyone option:

  

   

  This makes the dashboard form available to any user who has read privileges to the account entity. It does not override your security model, so if a user cannot see accounts, they won’t be able to see the dashboard form either!

   

• One final note: notice the All-Time Sales chart in the upper left part of the dashboard. As many of you know, it’s unfortunately difficult in Dynamics CRM to get all-up totals of child records from the context of the parent. There are certainly other ways to do it, but here’s one way that works in the dashboard context: I created a custom bar chart for Won Opportunities that groups the data by customer. When you filter a chart like that by the customer record – as the record-centric dashboard approach does – you get the sum total of Won Opportunities across all time for the account record. Normally I won’t tolerate charts with a single data point, but in this case I’ll make an exception!

There’s absolutely no doubt about it. That is my most cryptic article headline ever. I guess it’s what you get for trying to write snappy copy about practice tests for certification exams.

But I always try to write for my audience, and if you need to get certified on Dynamics CRM 4.0, you may be interested in the latest addition to my library of certification test-prep content.

First, though, if you want a good backgrounder on the core certifications for Microsoft Dynamics CRM 4.0, here’s a general article I wrote on the topic. Plus you can always visit the certification category on the Trick Bag: www.DynamicsCRMTrickBag.com/category/certification.

Anyway, a big part of what I do is help people prepare for the Dynamics CRM 4.0 certification exams. As part of that, I’ve authored libraries of practice test content for the three core exams. I’ve got 15-question sample tests available for free on this page, and if you’re a registered user on our brand new web site (www.IMGinc.net ) you get all the practice test questions (plus a complete set of recorded training sessions and some other goodies).

About a week ago I announced in my e-mail newsletter a special offer, available until the end of the year: for the crazy-low price of $100 you get a 6-month subscription to all of the certification-prep and related content for all three exams, PLUS the online version of my workflow book. Here’s a page with information on why and how to become a registered user.

It’s a pretty good deal and we’ve had good uptake since the e-mail went out. I also had a couple of new registered users ask me why the practice tests don’t contain explanations of the answers. Since I didn’t really have a good answer to that question, I thought I’d better start writing some explanations.

So here’s my first pass: five sample questions with video explanations from the practice test for the Customization and Configuration exam. Let me know what you think, and if you’re a registered user or about to become one, you will soon see a whole lot more of these.

Richard Knudson — richardk@imginc.com

As I’ve said more than a few times, SharePoint 2007 and Dynamics CRM have some interesting similarities and just as many important differences. Both have emerged as strategically important application development platforms, and I recommend a “right tool for the job” mindset when you’re trying to decide which one to use. Here’s a short article I wrote on Integrating Dynamics CRM 4 and SharePoint 2007, and here’s a link to an instructor-led training course I wrote for Microsoft on the same topic.

On important similarity has to do with the skills an organization will need to realize the potential business value of each application. Generally speaking, I like to characterize the skill sets like this:

• End-users – people who “live” in the applications every day and need to be productive in using the core feature sets.
• Installers – IT professionals who need to install, deploy, upgrade and maintain these applications, support users, and the like.
• Customizers – people who need to configure and customize the applications, but aren’t necessarily .NET developers and don’t necessarily write code.
• Developers – .NET/Visual Studio developers who need to extend the platforms and write custom applications.

My company (IMG – www.IMGinc.com ) provides consulting and learning solutions for SharePoint and Dynamics CRM. We’ve replaced the traditional open-enrollment one-size-fits-all public training schedule with something we think is better: training and mentoring customized to your requirements, delivered privately to your team, when and where you need it.

We’ve got a comprehensive curriculum for all the skills you need for both products – from end-users to advanced developers – and I encourage you to use the curriculum as a starting point to build just the skills you need. The following table lays this all out for each skill set and includes links to the detailed course outlines. I’ve also included the traditional instructor-led-training (ILT) course durations:

Our Delivery Model

Our delivery model bears little resemblance to traditional public training, so you should take the course timings in the table with more than a grain of salt! Our custom training and mentoring engagements are … well… custom, so while the timings give you a reasonable idea of how much learning content each course contains, they generally will not correspond to the actual calendar days of any particular engagement. Here are some of the most popular ways we customize our training and mentoring engagements:

• We work with you to determine the exact topics you need covered.
• We deliver a blended combination of live online and live in-person training and mentoring.
• We can use your data and examples to make the training more relevant.
• We provide ongoing support in the form of subscriptions to online classrooms with content, recordings and more.
• We combine our training and mentoring engagements with the delivery of custom solutions.

Basically, we can provide the assistance you need in installing, configuring or building custom solutions on SharePoint or Dynamics CRM, combined with the skills you need to be self-sufficient going forward. Whether your organization is an enterprise trying to realize the potential of these products or a Microsoft partner building a practice, I encourage you to contact me to discuss how we can make our skills-centric services work for you.

Regards,

Richard Knudson — richardk@imginc.com

Here are links to the demo versions of the most recent practice tests for the three core Dynamics CRM 4.0 exams. I call them demos since they have fewer questions than my full-blown practice tests, and they don’t randomize questions. Links to all of the practice tests can be found on the new Certification Prep page hosted on www.IMGinc.net 

I’ve authored a l0t more test questions than the ones in the demo tests, and I include the complete set of prep questions for each exam in the corresponding Skill-Pack subscription. These Skill-Packs are an outgrowth of my last couple years of delivering the CRM 4.0 Certification Bootcamps, on behalf of Microsoft, to the U.S. partner community.

Let me know what you think — I’d love to get your feedback on the questions!

Richard Knudson – richardk@imginc.com

Dynamics CRM 4.0 Language Packs – Multi-Lingual Out of the Box

Dynamics CRM 4 supports multiple languages almost out of the box with what we call “language packs”. A CRM 4.0 deployment has a base language baked into its license key, but you can drop a language pack on top of your base language and give users the ability to toggle the CRM user interface back and forth between the base language and any language added with a language pack. Language packs are free (they don’t do you much good without Dynamics CRM 4.0!), and you can download them from here: http://www.microsoft.com/downloads/details.aspx?FamilyId=50761E58-6040-4CF3-853A-F5AB535F7194&displaylang=en

To turn one on, follow these steps. (one language at a time, I’ll use Spanish for my example):

• 1. Download the language pack onto your CRM server machine.
• 2. Run the setup program. The file name of the Spanish language pack setup program is MUISetup_3082_i386.msi. The “3082″ part identifies Spanish as the language (English is 1033 in case you wondered.) Just double-click it and everything else is automatic.
• 3. After installing the language pack on the server it needs to be “enabled” from within CRM. Assuming you’ve got sufficient privileges (like the System Administrator security role), click Settings, Administration, then Languages. You should see the language you installed available for selection in the list. “Enable” it for your users by selecting the checkbox, and clicking Apply. (it takes a few minutes to enable the language, so plan ahead and make sure you have something productive to do at this point, such as visiting www.lulu.com/richardknudson and purchasing a fresh copy of my book on CRM 4.0 workflows) Here’s what the Language Settings dialog looks like with Spanish enabled:

 That’s pretty much all you need to do, as long as you’re using the web client. (the Outlook client requires a little more work – more on that in a separate article).

Now, any user can go to their Personal Options (Tools, Options, then click on the Languages tab) and select either the base language or the newly available language for their “User Interface Language” or their “Help Language”. (more discussion later on that distinction between the UI and help languages.)

This is a personal option, remember, so once a language pack is enabled, all users have the option of toggling back and forth between languages. Here’s what the languages tab looks like:

Immediately after selecting the language in personal options, the entire out of the box CRM UI switches to the selected language. Here’s what the web client looks like in Spanish, with the Ventas are of the site map selected:

One of the primary limitations of this method of learning a foreign language is that you develop a somewhat limited and very specific vocabulary. For example, here’s a more or less complete list of the nouns I know in Spanish, and their English equivalents:

 I also learned a relatively limited number of interesting adverbs (nouns that describe verbs):

 With just a little more study, I reasoned my way to a wider vocabulary. Here are just a few examples:

• When you make a nuevo ofertas and click Guardar , it has an Estado of Borrador.
• Both Campanas and Campanas expres can have respuesta de campanas. Both can also have activadades de la campana, but campanas expres can only have uno of those.
• Trabajo means “work”, and flujos means “flow”.

How fun is this?

On a more serious note, one of the really cool things about the out of the box experience is the nice job the CRM team did at translating the standard CRM reports. One of my favorite examples of this is in the reports for transaction entities such as Ofertas, Pedidos and Facturas (quotes, orders, invoices). From the standard forms for these entities you can run a nice report the takes very little (sometimes none) customization to share with clients. These translate 100% with the out of the box language packs. Here’s an example of what it looks like when you open a Pedidos forma and select Pedido from the Informes pull-down menu:

Handy Tools for Translating Custom Entities

You might wonder how custom entities get translated. If I create a custom entity called “Event”, how will the out of the box Spanish language pack translate it? The answer is, it won’t. All customizations must be performed in the base language (in my example, English), and if I have custom entities and toggle the UI into Spanish, my custom entities will still display in English. So if that’s as far as I go, I (and all my users) will have a mixed language experience.

There’s no magic AI tool that will translate everything for you, but if you have a translator, you can use the Export Labels for Translation and Import Labels for Translation utilities to make the translator’s job quite easy. Here’s an example to show how these work:

• 1. I created a custom entity called “Event”. (Remember, as I mentioned above, all customizations must be created in the base language; this means that if your base language is English, you cannot directly create the custom entity in Spanish)
• 2. I exported the labels for translation (click Settings, Customization, Export Labels…). This creates a zipped up XML file with the default name of CRMCustomizations.zip. I unzipped this and used Excel to edit the Excel-editable xml file it conveniently creates. Here’s what it looks like:

• 3. In the figure I’ve selected the “localized labels” tab, which contains the things that need to be translated. The labels in column c are the base language labels, which by definition won’t be empty. So all you need to do is locate the empty rows in column d (the Spanish labels in my example). These will be the non-translated labels for your custom entities, so all you have to do is fill them in, save, import the file back in, and publish. Presto – when I toggle to Spanish now, my Evento forma looks like this:

Notice that not only the more obvious labels (form display labels, say) can be translated, but also things like pick-list values. In the xml translation file, there was an empty column next to the “Other” value for Locacion de Evento, so I cleverly added “Otro” there.   

Granted, I only had one custom entity to translate for this example. During my flight to Mexico City I was seated next to a high-school girl from Berwyn and she graciously helped me with my translations. It only took about ten minutes; a more rigorous approach would of course require allocating some time & budget for a real translator, but the important point is that the translation effort doesn’t require any CRM knowledge.

Links to all of the practice tests can be found on the new Certification Prep page hosted on www.IMGinc.net

Let me know what you think. I’m interested in feedback about the test content as well as about the presentation and testing engine. The questions on these tests are a subset of the content I’ve developed and I’m toying with various ways of making the rest of the content available — I’d be interested in your feedback on that as well.

Recently I started experimenting with a test authoring tool included in an Adobe app called Captivate. Here’s my first public unveiling of some practice test content for the Dynamics CRM certification exams. I’m not very good yet at the test authoring tool, but I think the content is good, in the sense of being close to what the actual test questions are like.

Links to all of the practice tests can be found on the new Certification Prep page hosted on www.IMGinc.net

Let me know what you think!

Apart from one of my own, that is

I’ve written elsewhere that Dynamics CRM 4.0 Applications is the hardest of the three core Microsoft Certification exams. Here’s a detailed article I wrote about that particular exam, which I liked so much I took it twice, one week right after the next!

 Anyway, here’s my favorite non-Richard blog post ever, from Moira Heath’s CRM 4.0 Certification Blog, on MB 632 – Applications – The Aftermath.  

Check it out, and if you’re studying for MB 632, be sure to follow her advice on preparing!