Archive for March, 2010

Connectivity and Firewall Port Requirements in On-Premise Deployments

March 25, 2010 Leave a comment

The CRM Engineering for Enterprise aka E2 team is pleased to announce the release of another component of the broader CRM E2 Nuts and Bolts article on Security and Authentication in Microsoft Dynamics CRM –  the white paper Connectivity and Firewall Port Requirements in On-Premise Deployments, which is available for download from the Microsoft Download Center at:

Many data centers include firewalls between the end-users and the servers and other integrated systems that support an implementation of Microsoft Dynamics CRM 4.0. This document provides guidance on the connectivity requirements between Microsoft Dynamics CRM 4.0 and other systems to assist readers with proper firewall configuration in customer environments.

The CRM E2 team especially recognizes the efforts of Peter Simons, Roger Gilchrist, Mahesh Hariharan, Monika Borgaonkar, and CRM Product Development for contributing to and reviewing this paper to help ensure its completeness and accuracy. If you have any comments about the document or suggestions about how we might improve it, please comment below.


Jim Toland


Microsoft Dynamics CRM: Workflow Authoring Best Practices

March 24, 2010 Leave a comment

The Microsoft Dynamics CRM workflow engine provides powerful functionality for implementing custom business logic in a CRM deployment. However, it also lends itself to complex problems and design mistakes which can result in expensive maintenance and confused users. This article explains in detail a few important considerations when implementing workflows and custom workflow activities in CRM.

1. Composition with child workflows.

The workflow pattern is in general one of composition of smaller steps. Therefore, when creating a workflow, think about which parts of the workflow can be generalized as a “sub-process” and be reused in multiple workflow definitions. By isolating these smaller processes, one can define child workflows which can then be called from multiple workflow definitions. The advantage is that the child workflow can be easily modified as opposed to modifying multiple workflow definitions. It will also make it simpler to define future workflows that might be a composition of smaller processes or business logic. One important consideration is that child workflows are executed asynchronously with respect to the parent workflow. Therefore, you should not make use of child workflows for sub-processes which require sequential execution.

2. Awareness of persistence points in workflow definitions.

If you have a long workflow that might take a long time to execute you will need to consider whether the workflow will persist and what that implies. A workflow can be persisted because of multiple reasons: The workflow instance is waiting for some event to occur, the CrmAsyncService is stopped or the workflow instance explicitly requests to be persisted by executing an activity with the PersistOnCloseAttribute. In any case, the workflow engine unloads the workflow instance and persists it to the database until a user manually resumes the workflow or an event occurs which resumes the workflow automatically. The important considerations are

1) At what point does the workflow persist? The workflow will persist up to the step when the last activity is marked as a persistence point. Therefore, when it resumes, it will re-execute all the steps after the last persistence point. This is important if you have logic in your workflow which you want to guarantee does not execute more than once. Note that workflow instances are automatically persisted after the following CRM steps: create, update, send email, send email from template, assign, change status, child workflow and stage. For custom activities you can add [PersistOnClose] attribute to the activity class. (see

2) When is the workflow going to resume? If the workflow will wait on an event that might never happen or take years to occur, then the database will soon contain thousands of waiting workflows which could affect performance. You should consider a design in which this situation is minimized. For example a workflow that waits on an opportunity to be marked as “won” can wait forever and the condition never meets. Instead wait on the opportunity to be closed and then check the status reason once it is marked as closed; if it was not marked as “won” you might want to add a Stop Workflow step at that point.

3. Write “atomic” custom activities.

Custom workflow activities should not implement the entire logic of the workflow, they are ideally small “atomic” steps that will make part of larger workflows. Because custom activities don’t have the ability to control persistence, they should never cause the workflow to go idle or persist in the middle of a custom activity. Generally, it is better to have multiple custom activities that are called in sequence from a parent workflow than one large custom activity that implements all the logic in sequence. This also follows from the principle of workflow as a composition pattern. For example if your process is to take custom actions A, B and C when an account is opened, it is generally better to write a custom activity for each A, B and C separately and add a step for each activity in your workflow as opposed to writing a custom activity that implements A, B and C sequentially and then add a single step to the workflow to include this custom activity.

4. Correct use of “Execution Time”.

The CRM workflow designer provides a property called “Execution Time” which can be used in dynamic expressions such as “if Account(CreatedOn) + 10 days < workflow(ExecutionTime)”. The meaning of this property is neither the time at which the workflow is published nor the time the workflow instance starts. The actual value of this property is the real time when the workflow evaluates an expression that contains this property. Therefore, expressions such as “Wait until 1 day after workflow(ExecutionTime)” will never succeed and the workflow will wait and resume once a day forever causing performance problems. If you want your workflow to wait for a specific amount of time you should use the wait step and configure the condition as: workflow – timeout – equals – {Duation}. This will unload the workflow and resume execution after the specified time duration has passed.

5. Plugins Vs. Workflows.

This is a common dilemma in CRM and there is no exact formula to find the best implementation method for a specific situation. However, this article provides some general rules of thumb that can be used to decide whether to use a plugin or a workflow:


Gonzalo Ruiz

ISV Utilities for Comparing Customizations and Transferring Configuration Data

March 23, 2010 Leave a comment

Learn how to build and use two new powerful tools developed for Microsoft Dynamics CRM. The Customization Comparison Utility lets you compare the customization files between two Microsoft Dynamics CRM systems and the Configuration Data Utility lets you transfer custom configuration data from one Microsoft Dynamics CRM system to another.

Download the Visual Studio 2008 and Visual C# code samples for this article:

The Readme.doc files that are included with the sample code contain information about how to set up and build the sample applications. The user guides contain detailed information about how to use the sample applications and view the results. You can find the Readme.doc files and user guides in the project folder for each utility.

Applies To

  • Microsoft Dynamics CRM 4.0
  • Microsoft Visual Studio 2008


Microsoft Dynamics CRM is a highly customizable system. Not only you can modify different sections of the product, you can also create new components to address business needs. The Microsoft Dynamics CRM platform offers a robust set of tools, APIs, and documentation that helps you build custom business applications. As the applications built on the Microsoft Dynamics CRM platform become more and more complex, a need for specialized support tools grows. In this article you will learn about two very useful tools that help you analyze the impact of customizations on the system and maintain consistent configuration data across multiple Microsoft Dynamics CRM systems.

Evaluating the Impact of Customizations with the Customization Comparison Utility

To evaluate the impact of customizations, it is helpful to compare customization files between the source and the target systems before you import customizations. The Customization Comparison Utility helps you accomplish this task.

Analyzing Customizations

Often you have to export custom components from one Microsoft Dynamics CRM environment and import them into another, for example, from development into test or production. However, before you import customizations, it is very helpful to assess the impact of customizations on the target system. The system where you import customizations may have been changed since the last installation. You have to consider the extent of the changes and how they may affect the new installation. While some of the changes, such as renaming of the attributes or adding new attributes, are minor, other modifications, such as deletion of entities or changes in the forms may have a significant effect on the system.

Analyzing and understanding the system customizations may result in more successful deployment of a new version of the application. This analysis minimizes the risk of overwriting important customization data in the target system. For example, if only several attribute names have changed, you may be able to do a plain import using the import/export functionality built into Microsoft Dynamics CRM. However, if some key components were deleted, such as entity forms, you may have to merge the customizations with the changes in the target system. Comparing customization files between the two systems helps you determine which approach will result in more successful deployment. This is also very useful when you are diagnosing the problems between two systems. By comparing the customization files, you can often identify possible causes of the existing problems.

Using the Customization Comparison Utility

The Customization Comparison utility lets you easily compare two Microsoft Dynamics CRM customization.xml files. Unlike other XML comparison tools, this utility can read and understand Microsoft Dynamics CRM schema. The results of comparison show the differences in entities, attributes, forms, views, workflows, security roles, entity maps, and relationships. You can use this tool before you import customizations into a system to evaluate the effect they will have on the system.

Use the tool to compare XML customizations files between the source and the target systems. If you use a zipped customization file, make sure that it contains only one customization XML file. The following illustration shows the results of comparison between two customization files. The compared items include entities, roles, workflows, entity maps, and relationships. You can drill down into each item to see more details. From the entities, you can view the changes in attributes, forms, and system views. You can easily see the changes in source and target. It shows the items that are present in the source file and not present in the target file and the items that are present in the target file, but not in the source file.


In addition to reviewing the results of the comparison in the grid, the tool includes a report that you can easily export to Microsoft Office Excel for additional analysis.

For more information about how to use the tool, see the Customization Comparison user’s guide included in the download package for this utility.

Transferring Configuration Data with the Configuration Data Utility

When you work with multiple environments, such as development, test, and production, or multiple Microsoft Dynamics CRM organizations, keeping consistent configuration data across all systems can be very important. The Configuration Data Utility helps you achieve this. It lets you export custom configuration data from a source Microsoft Dynamics CRM system and import it to a target Microsoft Dynamics CRM system.

Storing Configuration Data in Custom Entities

In Microsoft Dynamics CRM you often use custom entities to store business information. However, you could also use custom entities to store system configuration data. For example, if an application integrates Microsoft Dynamics CRM with a third-party system, you could create a configuration entity with attributes such as pollingtime, url, and retries to store the configuration data needed for the integration. This is very convenient because the data stored in the configuration entity can be used by the system administrators to configure a new application or update an existing application. To keep the configuration data up to date, you may have to frequently upload the new data, or have an automated task to do it.

Using the Configuration Data Utility gives you a simple and efficient way to transfer custom configuration data from one system to another. One of the main benefits of this utility is that you can import configuration data from multiple custom entities at the same time. While it only imports and exports data for custom entities, the tool can handle useful scenarios, such as importing records that reference other records that are also being imported.

Dd442453.Important(en-us,MSDN.10).gifImportant: For the tool to work correctly, the schema for the source entities and the target entities must be identical.

Dd442453.note(en-us,MSDN.10).gifNote: In more complex cases, use the Microsoft Dynamics CRM data export and import tools or Data Migration Manager to transfer data for custom and system entities.
For more information about these tools, see Microsoft Dynamics CRM online Help.

Using the Configuration Data Utility

Use the Configuration Data Utility to export the source system configuration data and import it into a target system. The tool provides a convenient interface that lets you select the custom entities that contain the configuration data in the source system, save the data into a data file, and then import the records from the data file into a target system.

To run the tool, you must be a system administrator with appropriate privileges to create, read, and update entity instances.

The following illustration shows the entities in the source system that are selected for export.


For import, specify the target server where you import the configuration data and the data file that you created during export, as shown in following illustrations.



The tool offers a command line version that you can run from a command prompt.

For more information about how to use the tool, see the Configuration Data Utility user’s guide included in the download package for this utility.

Additional Information

Download the Microsoft Dynamics CRM 4.0 Software Development Kit (SDK) from the Microsoft Download Center.

For more information about custom entities, see Entity Customization.


Inna Agranov

Internet Leads – How to start and grow your business online

March 23, 2010 Leave a comment

Internet Leads are prospective customers interested into your business online. You can use your favorite search engine marketing tools or expertise as a starting point for integration into a solution using Microsoft Dynamics CRM Online.

Online Lead Generation is a marketing term that refers to the creation or generation of prospective consumer interest or inquiry into a business’ products or services online. Let’s take a basic example and see how we can create a landing page and how we can use the page to collect Internet Leads.

Step 1: Navigate to Internet Lead Capture

Internet Lead Capture is present in the Sales and Marketing areas. In this example we will use the Sales area to create a Landing Page and collect Internet Leads.


Step 2: Create a landing page

A landing page it’s a web page that captures information about the potential customer. Using CRM Online you can customize the page layout.


Clicking Create Page button will open the following dialog where you can customize the look and feel (colors and form layout):


Step 4: Form content

Clicking next will open the form customization where fields can be added or subtracted to suit the business need:



Step 5: Confirmation page

Once the form is customized we can get a preview of how it will look like.


Step 6: Lead collection

The screen is giving us some tips of how to make the url that we just created known to potential customers (e.g. by including it in an e-mail campaign or on a marketing webpage):


Step 7: Test the page

Once the page is created we can go ahead and test ourselves the page.


Step 8: Importing Internet Leads in CRM

Internet leads tab contains all the details collected for each individual Internet Lead.


We can select which ones we like to import into CRM (assigning to me or somebody else in the organization) delete them or Export to Excel. If we choose to import into CRM, the Internet Lead will be moved to CRM and the entry will removed from the Internet Leads page.


Here is a screen shot of how our IL looks like in CRM. Notice in the Topic that Internet Marketing is mentioned.


Step 9: Internet Leads statistics

Internet leads capture provides also some insights into how many leads we got per month or what is the performance of our Landing Page.



Doru Rotovei

Microsoft Dynamics CRM Automatic Customizations

March 23, 2010 Leave a comment

Microsoft Dynamics CRM has recently released November 2009 Service update for Microsoft Dynamics CRM online. One of the key features delivered as part of this release is enhanced Import Data Wizard. To familiarize yourself with the new capabilities of enhanced Import Data Wizard, follow the link Introducing-the-import-data-wizard. Some of the features like automatic customization, importing multiple files, creating new record types on the fly make Import Data Wizard extremely powerful.

One of the powerful features of Import Data Wizard are the automatic customizations of field width and list value, which will make customers life easier while importing data. Let us look at the highlights of Import Wizard that make importing data a pleasant experience.

Field Width Customization

Field width customization means customizing the length of Microsoft Dynamics CRM field on the fly based on the length of data in source file.

Often when user wants to bring data from some other system to Microsoft Dynamics CRM system, there are certain fields whose length in source system and target system varies. Let us say we have the name field in source system which maps to Account Name field. The default setting of length for “name” field of account record type in Microsoft Dynamics CRM is say “100” and maximum length of data in that column, among all rows in source file for field “name” is having length say “320”. Length of the field needs customization in order to import these rows. There are two ways of customizing Microsoft Dynamics CRM to accommodate the source data:

1. Manually increase the width of field by going to customization area.

2. Use Import Data Wizard for automatic customizing of field length while importing data

Now we have understood what we mean by automatic customization of field width. In the following section, we will see the data types on which Import Data Wizard allows field width customizations.

Data Types Supported by Field Width Customizations

First a few definitions so that we are all talking about the same things:

  • Text fields: – typically used to store short length information that can include letters, numbers and characters.  Examples include names, addresses, job titles, etc.  By default, these fields hold up to “x” characters but can hold significantly more. “x” can be different for different fields and record types and default value of “x” can be known by going to customization area.
  • Ntext fields: – used to store larger amounts of text information for users such as descriptions.  Ntext fields can hold up to 10,000 characters.  The default setting for ntext field is 2,000 characters. In case data exceeds the max limit of field, then user will get the error while importing such record.

When import data wizard encounters a mismatch in the field lengths of source data and target field it deduces following:

1. Is the field customizable.

2. Finds the maximum length of the source data in respective column of given source file.

3. Checks whether the length found in step 2 is more than the default length of the field and is less than the maximum allowed length for the Text column (which is 4000).

If both conditions mentioned in Step 3 are satisfied, it updates the metadata of an attribute to the length found in step2 and changes the column length in database.

Field Width Customization for advanced transformations

Import Data Wizard applies field width customization even if some advanced transformations like Concatenation are applied on source data, and concatenated data is then mapped to some CRM field. If the data obtained after concatenation has length more than the default length of the field to which it is mapping, Import Data Wizard will apply field width customization in that case also.

Field width customization on logical fields

If you want to import data into some logical field whose data does not get stored in same record type, instead it is stored in some other record type in Microsoft Dynamics CRM then in those cases you need to customize the length of field where exactly data gets stored in Microsoft Dynamics CRM by using CRM application customization. Once you have customized the system you can use the Import Data wizard to import data of more length into logical fields also.

Text entered exceeds maximum length or “Generic SQL error”

Most frequently observed error is “Generic SQL error” and the most common cause of this failure is when field size of source record is more than the default setting of Microsoft Dynamics CRM and CRM is unable to customize the system automatically. Whenever such failure occurs, change the field width by using CRM application customization and then try to re-import the failed records.

Picklist customization

Picklist customization means automatically customizing the list values in Microsoft Dynamics CRM system to accommodate the source picklist values. As you might already know that picklist values are stored in CRM as values (1, 2, 3 … etc) and not by the label. When user wants to import data into Microsoft Dynamics CRM for picklist fields, following possible cases can occur:

  • The source file has some new picklist values, which does not exist in CRM and user wants to bring the records with this new value into CRM.
  • The source file has some values that do not exist in CRM, instead of creating new picklist values in CRM user wants to map the certain picklist labels to CRM existing labels. This is out of scope for this blog and more information on how you can achieve this can be found at Picklist import.

Import Wizard can handle the picklist customization when user has chosen Map Automatically or has chosen to Use and existing data map while importing data. Let us see how Import Data Wizard handles the picklist customization in case user has chosen Map Automatically.


1. Identify all the unique values of the column in source file, which is mapping to picklist column.

2. Identifies which source values are having an exact string match with Microsoft Dynamics CRM fields’ picklist string values and can be imported without additional customization.

3. To create new picklist value for the unmatched source values, system verifies:

     a. Whether the number of new picklist values which need to be created is less than 400 else system fails the entire import file.

     b. If the target field is customizable. Pick list is not created unless the field is customizable and those      records fail with appropriate error otherwise.

     c. In case field is customizable then system creates new picklist values in CRM with the same label as that specified in source unique value.

Let us take an example to understand what happens when Import Data Wizard finds a column in source file, which is mapping to picklist type field in MSCRM.

Is a column which is mapping to picklist field of CRM “prefferedcontactmethodcode”


Let us assume we want to import the following data file.


User maps the source file to Account record type in MSCRM by going to Map Record Types page of Import Data Wizard. After user has mapped the record type to which the source file maps user can map the columns to fields on Map Fields page of Import Data Wizard. The name column of the source file will be mapping to Account Name of account record type and PrefferedContactMethod to Preferred Method of Contact as shown below.


Preferred Method of Contact field has some unique values in CRM that can be seen by navigating to:

             Settings –> Customizations->Customize Entities->Entity Form->Attributes-> Attribute page


As shown above the unique Picklist values in CRM does not have value Mobile in it. Once the source file has been imported using Import Data Wizard, the new picklist value Mobile will be added to Preferred Method of Contact field. We can see that Account4 which was having new picklist value Mobile got imported with Mobile added to list as shown below.


However, if a map is being used instead of automatic mapping then the system customizes pick lists on the basis of map. Handling of picklist customization in case user has chosen the Use an existing data map option is same as that of automatic mapping except that in this case in addition to the existing values which exist in CRM here we also need to resolve the values on the basis of any mapping which are defined in map. The picklist transformations go in this order:

1. Picklist values which exist in map.

2. Existing picklist values in CRM.

3. Any new picklist values which need to be created as part of picklist customization.

So here you go! With the new Avatar of enhanced Import Data Wizard you need not bother about the field width and picklist customizations while importing.


Veeran Bansal