This documentation is archived and is not being maintained.

Customization Best Practices

banner art

[Applies to: Microsoft Dynamics CRM 4.0]

Find the latest SDK documentation: CRM 2015 SDK

The following is a list of best practices to follow.

Using Custom Entities and Attributes

ISV solutions can save data by using:

  • Custom attributes on existing entities
  • Custom entities
  • A separate database
  • Use entity rename to make system entities more meaningful

You should use a unique prefix for custom entities and attributes. For example, use an abbreviation of your company name to avoid conflicts with other ISV add-ins.

Using Isv.Config.xml

Microsoft Dynamics CRM ships with a sample configuration file in the wwwroot\_Resources folder. To prepare for installation of ISV add-ins you should rename this file and then create your own configuration file. By doing this you will not confuse the sample UI changes with the UI changes you need for your customization.

ISVs should merge changes into the existing ISV.Config file and not overlay the existing configuration file.

When Do I Add vs. When Do I Customize an Entity?

You should customize a system entity, such as the account entity, rather than replace it because there are many built-in features that you would have to recreate. For example, the account entity has lookup fields to associated customers. You can use the entity rename feature to make the system entity more meaningful to your business.

How Can I Tell What Customizations Have Been Made to a System?

If you develop custom solutions and you want to learn about a tool that you can use to compare customization files to see what customizations have been made, read the following technical article in the Microsoft Dynamics CRM Developer Center: ISV Utilities for Comparing Customizations and Transferring Configuration Data. You can also read about a tool that allows you to transfer custom configuration data in the same article.

When Do I Use a Workflow .NET Assembly?

Workflow rules cannot create an instance of an entity. You can use a .NET assembly to do this.

When do I use plug-ins vs. workflow?

As a developer who is interested in extending or customizing Microsoft Dynamics CRM, you have several methods of performing your tasks. In addition to adding client-side JavaScript code to a form, or adding custom ASP.NET page, you can choose to write a plug-in or create a custom workflow by using the Web interface that calls a custom workflow activity. But how do you decide when you should use a plug-in or when you should use a workflow? The technology that you choose depends on the task that you have to perform.

For example, you must use a synchronous plug-in if you need to execute custom code immediately before or after the core platform operation executes and before the result of the operation is returned from the platform. You cannot use a workflow or asynchronous plug-in in this situation because they are queued to execute some time after the core operation executes to completion, and so you are not guaranteed when they will run. On the other hand, if you want to add custom functionality to Microsoft Dynamics CRM Online, only workflows are supported because you cannot add your DLL to the server.

As a developer, you will have to evaluate both technologies and choose the one that best suits your business objectives after considering deployment, performance, and maintenance concerns of your plug-in or workflow solution.

The following table summarizes the characteristics of plug-ins and workflows.

Criteria Plug-in Workflow
Execution before or after the core platform operation (Create, Update, Delete, and so on)Executes immediately before or after the core operation (synchronous).

Can also be queued to execute after the core operation (asynchronous).

Queued to execute after the core operation (always asynchronous).
Performance impact on the server1Synchronous plug-ins can increase the platform's response time because they are part of the main platform processing.

Asynchronous plug-ins have less impact on server response time because the code is run in a different process.

Less impact on server response time because the code is run in a different process.
Security restrictionsTo register a plug-in with the platform requires a System Admin or System Customizer security role and membership in the Deployment Administrator group.Users can interactively create workflows in the Web application.

However, to register a custom workflow activity, the deploying user must have the same security roles as those required for registering plug-ins.

Microsoft Dynamics CRM version (SKU) supportNot supported in Microsoft Dynamics CRM Online. May be supported in partner-hosted installations.Workflows without custom workflow activities are supported by all product versions. Workflows that call custom workflow activities are supported the same as plug-ins.
Length of processing timeA plug-in registered for synchronous execution is best used for short processing tasks.

A plug-in registered asynchronously can be used for process intensive operations. However, an asynchronous plug-in can only execute after the core platform operation has completed.

Works well for either short or long processes.
Works when the CRM for Outlook client is offlineBoth online and offline are supported.Workflows do not execute when offline.
Process and data persistencePlug-ins execute to completion.Workflows can be paused, postponed, canceled, and resumed through SDK calls or by the user through the Web application. The state of the workflow is automatically saved before it is paused or postponed.

1 – There is no significant performance impact on the server between an asynchronous plug-in and a workflow.

Can I Define Custom Entities that are Specific to Business Units?

Custom entities have privileges per role but not per business unit. To define custom entities that are visible only to specified business units, you must create different roles for each business unit, granting privileges to the custom entity in the appropriate role.

See Also


Other Resources

© 2010 Microsoft Corporation. All rights reserved.