Saturday, December 12, 2009

Customize Dynamics CRM 4.0 entities print preview forms

(Changing the entity’s default print preview to a custom implementation)

One of the most annoying drawback which was raised by my clients ever since CRM 3.0, was the dull and inflexible print preview form of CRM entities. Needing to print out every day several types of records on such print previews and file them, turned out to be a real burden using the default print preview.

The main complaints were about:
- the layout of the print preview form is not customizable (layout, position of fields, adding or removing fields etc)
- the look (the design) cannot be customized (e.g. adding a company logo, colors, fonts, etc)
- the child collections’ information cannot be added to the print preview screen

One of the most efficient approaches to implement your own print preview page for any entity form is to perform the following steps:
1. create a custom CRM / SSRS report to be used as print preview for that entity
2. update the file with a code which checks if there is a custom report defined for the current entity to be loaded instead of the default print preview. In case there is one, the customization will load that report page instead of running the default print preview page.

- Add in Global.js file an array with the entities supporting custom reports for print preview:

var PrintPreviewReports = new Array(); PrintPreviewReports[Lead] = "Print Leads"; //This is the report name

- Add the following code in the at the beginning of Print() function:

if(PrintPreviewReports!=null && PrintPreviewReports[_oSubmitForm.crmFormSubmitObjectType.value]!=null) { RunReport(true, PrintPreviewReports[_oSubmitForm.crmFormSubmitObjectType.value], "", _oSubmitForm.crmFormSubmitObjectType.value, PrintPreviewReports[_oSubmitForm.crmFormSubmitObjectType.value]+".rdl", 1);}

The approach is rather simple for a developer; once the customization has been set in place and you have a first model for a report, then it should take about 30 minutes per each new report to implement in order to be used as entity print preview.

Here’s the sample screen for this solution in production:

That’s it. Let me know if you find this useful.


Manage email campaigns efficiently from CRM

(A low-cost but more powerful solution for handling email campaigns from CRM by integrating an external emailing tool)

There are several good solutions out there which come as CRM extensions designed to manage the emailing campaigns in CRM. However, none of them seem to offer the same range of functionalities (managing, tracking, reporting etc) as a dedicated mailing tool would.

Given this reasoning, I’ve concluded that the most satisfying approach to handle this case is to integrate / automate an external dedicated tool designed to handle mailing campaigns.

A brief list of advantages for using an external mailing tool are:
- The price of a campaign mailing tool is in the same range (sometimes even lower) with a CRM extension’s price
- The list of features (especially editing, tracking and reporting) of a mailing tool is generally far wider then the features list of a 3rd party CRM extension.
- The mailing tools follow generally an evolution roadmap from its producer so that upgrading your application instance on a regular basis could get you a new set of improvements & fixes.

The custom integration of an external mailing tool should consider the following points:
- pick a mailing tool having a web-based UI
- the domain model of the chosen tool should be similar to the one of CRM’s (e.g. have the same notions of campaign, mailing list, subscribers etc)
- the campaign in CRM should have a customization (e.g. a button) to export it towards the external tool
- the campaign in CRM should be automatically updated every time when a change of its counterpart in the external tool occurs (e.g. status of the campaign, recipients unsubscriptions, campaign stats etc.)

This list of integration points above should be kept small and should not take more than 3...5 man-days to implement for a CRM developer.
Once the bidirectional integration between the two systems is up, you could benefit from all the feature of your mailing tool and have direct access to each external campaign screen from the CRM campaign editing form.

Here are some screenshots of such an integration in production. I used here a good money-for-value tool called OemPro which managed to cover a wide range of my client's requirements.

That’s it. Let me know if you find this useful.


Tuesday, December 1, 2009

HTML WYSIWYG editors in CRM Forms: A non-intrusive approach

(Transforming a text area field of a Dynamics CRM form into a HTML editor, using a non-intrusive way)

You might have already came across the need to have some of your text fields in the CRM forms support HTML code. There are several solutions out there on how to handle this point, but in this article I’d like to focus on the approach I prefer: the most non-intrusive approach.

The main idea is to define my CRM text fields to be displayed as text areas (from the entity’s customizations section) and at runtime - on form load - have some of these fields (the ones which need to store HTML strings) get decorated with a WYSIWYG HTML editor. Consequently, no server side code or other special handling of these fields would be required, but, unlike other solutions you might find, no further client-side code to be executed on form save event is required either.

Here are the steps to implement it:

1. Take a JS-based HMTL editor with the capability to render itself around an existing text area control (instead of letting the control creating a new element in the document).
I used for this purpose the openWYSIWYG editor.
Download the code and include a reference to the editor's JS file from your Global.js file.

2. Have the OnLoad events of the forms execute the initiation code for each text area which needs to be transformed into HTML editors.

That's it.

Here’s a screenshot of this implementation in production:

Let me know if you find this useful.