Workflow Plugin CRM Online Compatibility

There are a lot of useful free add-ons available for Dynamics CRM that can add some serious customization features. The issue in many cases is that these add-ons were only released for the on-premise version of CRM.

For example, take the very useful CRM Manipulation Library which contain some important calculation capabilities. I especially find the Date Utilities to come in handy as there is often a requirement to calculate an off-set of days or business days as part of workflow logic. But when you try import the solution into a CRM Online instance you will receive an error that looks something like the following:

The good news is that this can be made compatible with CRM Online by following these steps:

1. Unzip the solution into a folder
2. Open the customizations.xml file
3. Perform a search for the IsolationMode node
4. Change IsolationMode value from 1 to 2
5. Update the original zip file with the modified file

Once you have done so you should be able to import it into CRM Online. Applying this trick does not necessarily mean that the plugin will work as it might fail on something when trying to execute. However it also just may function without a problem which is indeed the case with the CRM Manipulation Library. So it's definitely worth a shot. If your plugin does not work after performing this tweak, you'll have to do some debugging at the code level.

Deleting iPhone Contacts

One of the side benefits of writing blog posts is that over time you create your own knowledge base that you can refer to. I know I am not alone when I say that there have been countless occasions where although I seem to recall having implemented a particular solution in the past... only to struggle to figure out exactly where, when and how it was performed. My experience is that once you have blogged about a topic, it is much more likely to be registered to long term memory which when combined with the power of search... voila! I guess blogging is an example of the proverb: "You never really own something until you're able to give it away" (Bill Nichols).

In light of that long-winded intro...

As part of rolling out the Outlook client functionality to end users we needed to of course clean up existing contacts so that duplicate contact records are not created when syncing from CRM.

In most cases, this is just a matter of cleaning up your Outlook contacts because Outlook contacts sync to the various mobile apps so cleaning up in Outlook results in a clean up everywhere else.

We were however presented with a case where the contacts were stored directly on the iPhone and we needed to get rid of these. Given that various users had thousands of contacts going through the list was not really an option.

Fortunately we were able to purchase a very inexpensive iPhone app in order to solve the problem. The app name is Contacts In : Import CSV & Manage Groups. Steps:

Select All Contacts:

 Click Action menu and choose "Delete contacts":

Spell Checking Options

I came across this topic in my email archives. I think it's still a relevant topic so I thought I'd post it. It deals with options for spell checking within Dynamics CRM.

One of the simplest options of course is to use the spell checkers that come built into the various add-on toolbars such as the Google toolbar.

More sophisticated options employ the use of a spell checker API where the experience is similar to spell checking in applications such as Microsoft Word.I have implemented 2 such versions of the spell checker.

The first one powered by webspellchecker.net is a paid for solution ($250 per year for up to 10000 sessions and then $0.025 for each additional sessions - see web site for additional pricing options). This tool is very intuitive and will be familiar to anyone who has used the Microsoft Word spell checker solution.

The second option was to use a free product called NetSpell – this is deployed on the server entirely i.e. the check occurs against a dictionary defined on the server. This tool is also fairly intuitive however the way in which the spell checker works is not quite as comprehensive as that as webspellchecker.net which I think is in evidence by comparing the screenshots.

In summary, below  are the pros/cons of each approach:

webspellchecker.net Pros

• Quite a bit more comprehensive in terms of functionality including an easier to use interface as well as grammar and thesaurus options
• Very intuitive
• Allows for custom dictionary to be defined
• Is a supported product and will be maintained over time presumably with incremental improvements, dictionary term additions, etc.

webspellchecker.net Cons:

• Is not free. $250 per 10000 sessions. To get a true cost it is necessary to determine the number of users who will be using this on a daily basis multiplied by the number of times they are likely to use it per day e.g. the formula would look something like: #users*#dailysessions*200 (200 being roughly the number of work days per year)
• Is an online solution although there is also a licensed downloadable version for a not insignificant cost

NetSpell Pros

• Fairly comprehensive
• Fairly intuitive
• Allows for custom dictionary to be defined
• On premise solution so not reliant on network performance
• It is free

NetSpell Cons

• Is not a supported product in case of product issues
• Dictionary is not auto maintained
• User interface not as slick as that of webspellchecker.net 

Searchable Property Updater

I may be a little late to the party but I've recently discovered the "Searchable Property Updater" tool and I have to say that this rates as one of my all time favorite CRM utilities.

Because it addresses a pretty much inevitable need. That is, if improving usability is a major concern in a CRM installation... Out of the box pretty much all fields are searchable. Most are irrelevant in a given implementation e.g. latitude and longitude on the account and contact record. In fact, I'd venture to say that most of the highlighted fields below are going to be irrelevant in most CRM implementations. And that's just a small snippet...

In this case, "usability" means "simplicity". And weeding out the irrelevant values really helps with keeping the UI clean and simple. Confusion being the enemy of a successful implementation, I personally consider this to be a very important tweak.

Of course in CRM you are able to weed these out albeit very ... t e d i o u s l y ... by updating the searchable property. And of course tedium often leads to the lack of execution - important or otherwise.

That's why this tool is so valuable. It removes the tedium and makes it what it should be - a quick and virtually painless effort.

I especially love the "Check Attr. on Forms" option. That is pure genius and really contributes to the painlessness of this task. In most cases, the fields that you have on your user form are the fields that you are going to want to query via Advanced Find. Or at the very least - it's a good starting point. And you can just click that to automatically select all the form fields and deselect everything else. Publish and you're done.

Brilliant! Better late than never but big kudos to the creator of this utility.

Views and Filters Toolkit for CRM Online

While on the subject of CRM Online compatibility - below is a link to the CRM Online compatible version for the "Views and Filters Toolkit" workflow plugin - another exceedingly useful utility. The one currently uploaded in CodePlex fails import into the CRM online environment.



Though there are many conceivable uses for this utility, I find that the ability to update the Offline and Outlook Filters without having to resort to programmatic techniques is perhaps the most useful. A simple way to centralize the maintenance of these download rules has long been a feature missing in the Dynamics CRM product and this utility surmounts this oversight.

Another shout out to Wayne Wittman for his conversion efforts (not to mention the efforts of Alberto Gemin who first published this utility).

As a related aside... another useful utility - namely the CRM 2011 Workflow Utilities - has also recently been updated in its CodePlex location with a CRM 2011 Online compatible version.

Distribute Workflow for CRM 2011 Online

I have spoken previously quite extensively about the virtues of the Distribute Workflow utility. The problem I encountered was that the version that is currently uploaded in CodePlex cannot be imported into CRM Online.Whenever I tried the import would fail as shown below:

But thanks to the efforts of the talented Wayne Wittman this very useful utility has now been made compatible with CRM Online. This utility can be downloaded using the link below.

Announcement: CRM Grid Editor now freely available

Until now the Limited Edition CRM Grid Editor has been available as a free add on. This edition has been limited to working with out of  the box entities and views. As of today, I am pleased to announce that this restriction has been removed. You can now obtain a free and unlimited version of the CRM Grid Editor which can (drum roll) also be configured to work against custom entities and views.

The CRM Grid Editor works with all versions of Dynamics CRM - on premise, online and IFD.

You can get an overview of product capabilities by viewing the CRM Grid Editor Summary video. You can also view the product installation video.


In order for you to be able to use the product it is necessary to generate a license file for your installation. To obtain a license please send me an email (see details in Contact tab) with the following information:

On Premise
Provide your CRM server URL and organization as shown in the screenshots below.

Online:
Specify the org name that you are using to access CRM i.e.: https://orgname.crm.dynamics.com



Key features:

• Simple and intuitive Excel-like interface 
• Edit all editable CRM fields returned in view (all data types handled) 
• Based on CRM view definitions – no additional setup required 
• Bulk update of records – make changes on the fly without having to save between row edits 
• Launch Grid Editor from context sensitive CRM user interface or as a fully navigable standalone application 
• Drill down to child records from a parent record – not limited to the associated view! 
• CRM Security model enforced – you cannot do anything with the Grid Editor that cannot be done through the standard CRM user interface 
• The Grid Editor can be configured to work against all CRM entities and views – including custom entities and personal views 
• Tabbed interface allowing multiple different views to be open at the same time 
• Ability to define and save "GE Views" which allows for advanced pivot table-like grouping and filtering 
• Add new records using the CRM standard, quick or the new Grid Editor view sensitive add-new form 
• Run CRM workflows against selected records

Other features include:

• Deactivate and Activate records in line 
• Manually execute CRM workflows 
• Link back to CRM records with a single click 
• Advanced additional filtering and sorting options 
• Easy to identify color for changed cells, columns 
• Dynamic export to Excel 
• Supports opportunity and case close forms 
• Supports Drag and drop editing and Undo Changes Requirements:

CRM 2011 Copy Utility

This plugin allows you copy fields from a parent record to all child records in a 1:N relationship. For example, this plugin can be used to copy the address fields of an account to all the contacts of that parent account (a common scenario).

Out of the box you are able to map fields from a parent entity to a child entity when the child record gets created. However beyond this point in time if details are changed on the parent record they will no longer be copied to the child records. Similarly there is no out of the box capability to copy changes made to the parent record down to all child records.

This plugin allows this option to be configured. You are able to configure which 1:N relationship this plugin will work against as well as the fields that are to be mapped between the parent and child entities. The plugin does not validate attribute types so you will need to ensure in your configuration that the fields be mapped are of the same type.

The following is a walk through of how to configure this plugin:

• Download the DLL from here
• Use the Plugin Registration tool to connect to your environment and register the plugin

• Register a New Step 
• Message: Update
• Primary Entity: Parent entity
• Remaining settings: Optional

• In the Unsecure Configuration update the XML to specify the fields to copy
• <setting name="source"> : parent entity name e.g. account
• <setting name="sourceid"> :  parent entity primary key e.g. accountid
• <setting name="target">  : child entity name e.g. contact
• <setting name="targetid"> : child entity foreign key e.g. parentcustomerid
• <setting name="numberoffield"> : total number of fields being copied
• <setting name="src_fieldn"> : name of source field to copy
• <setting name="dest_fieldn"> : name of corresponding target field to be copied too

Note: There is no validation of any of these fields. You need to ensure that:

• All the field names are correct
• The corresponding "src" and "dest" fields have the same definition 

For example, the following XML can be used to copy the address fields from the parent account record to the child contact records: 

<Settings>
<setting name="source">  
<value>account</value>
</setting>
<setting name="sourceid">  
<value>accountid</value>
</setting>
<setting name="target">
 <value>contact</value>
</setting>
<setting name="targetid">
 <value>parentcustomerid</value>
</setting>
<setting name="numberoffield">
 <value>8</value>
</setting>
<setting name="src_field1">
 <value>Address1_line1</value>
</setting>
<setting name="src_field2">
 <value>Address1_line2</value>
</setting>
<setting name="src_field3">
 <value>Address1_line3</value>
</setting>
<setting name="src_field4">
 <value>Address1_city</value>
</setting>
<setting name="src_field5">
 <value>Address1_stateorprovince</value>
</setting>
<setting name="src_field6">
 <value>Address1_postalcode</value>
</setting>
<setting name="src_field7">
 <value>Address1_country</value>
</setting>
<setting name="src_field8">
 <value>Address1_telephone1</value>
</setting>
<setting name="dest_field1">
 <value>Address1_line1</value>
</setting>
<setting name="dest_field2">
 <value>Address1_line2</value>
</setting>
<setting name="dest_field3">
 <value>Address1_line3</value>
</setting>
<setting name="dest_field4">
 <value>Address1_city</value>
</setting>
<setting name="dest_field5">
 <value>Address1_stateorprovince</value>
</setting>
<setting name="dest_field6">
 <value>Address1_postalcode</value>
</setting>
<setting name="dest_field7">
 <value>Address1_country</value>
</setting>
<setting name="dest_field8">
 <value>Address1_telephone1</value>
</setting>
</Settings>

• Register a New Image called "postEntityImage"

• Test and ensure that it is working

Form Query String Parameter Tool

The Dynamics team recently released a new utility called the Form Query String Parameter Tool. Essentially it's a useful little utility that can be used to generate the syntax of a create form URL passing in parameters to default field values when the new form is opened.

Having said that, I believe that in in most cases using the URL parameter passing approach for defaulting values on the create form should not be necessary. The rest of this post will explain this point of view.

First of all, the out of the box "field mapping" approach - whereby field values from the currently open parent entity are mapped to the child entity form being opened - should be used where ever possible. This covers scenarios where the default values are static regardless of the form "context" and the field being mapped is in fact "mappable".

If the default values are dependent on the form "context" (e.g. new accounts where type = "customer" should have different defaults than cases where type = "vendor") or if the field being mapped is not "mappable" then your next best bet is using javascript on the form load event to set the defaults. Using javascript you can set all the appropriate fields as long as you have a field populated on the form in order to make the necessary branching default logic (the form "context" field). The form context field may be set using either standard field mapping, a web service API call (as explain below) or via URL parameters. Once obtained the javascript default logic can take over.

Using the URL parameters approach would therefore only seem to be necessary when you don't have a form "context" field on the form that is being opened. However this is not necessarily the case either since you can also leverage the web service calls (RESTful or SOAP) in order to retrieve the "context" from the parent field in order to perform the necessary branch logic.

Therefore it would seem that using form parameters to set default values would be necessary to only a fairly limited set of scenarios. This would be a scenario where all 3 conditions listed below are true:

• The fields cannot be defaulted via standard parent/child field mapping
• The form does not contain a form "context" field on which to base javascript branching logic
• A standalone form that is not linked to another form from which the "context" can be retrieved using web services

Finally, even in the remaining few scenarios that do require the URL mapping approach, it is really only necessary to pass through a single URL parameter - that will set the context and javascript can subsequently take over for the remaining default logic.

Therefore, when all is said and done, while it's always nice to see new tools being developed to facilitate the customization effort, I do not see myself using this particular one all too frequently.

Perhaps there are scenarios that I'm not considering? If I encounter them I'll be sure to dish.

One scenario encountered is with differentiating between multiple 1:N field maps for the same two entities as described in this post.

Dynamics CRM 2011 Instance Adapter Released

Yesterday the Dynamics CRM team announced the release of the Microsoft Dynamics CRM 2011 Instance Adapter. The following is the description that was provided for this tool:

This is an additional adapter for use with Connector for Microsoft Dynamics that allows for the synchronization of data between two Microsoft Dynamics CRM 2011 organizations. The adapter allows for communication between two endpoints that exist on any authentication/hosting environment (on-premise, online, IFD, etc.) This means that you can leverage this new adapter to move Microsoft Dynamics CRM 2011 data between test and production servers or from on-premises to the cloud.

Interesting.

This would seemingly provide a solution to a situation that is encountered all too frequently. Namely that the data in the test or staging environment becomes stale and consequently does not provide a good testing ground without performing a refresh. Until now, the only way to do that has been to backup the production database and then import it to refresh the test environment. Something that can take a while to accomplish especially with the larger CRM databases out there. Not to mention that such a refresh would also overwrite development deltas made in those environments that would need to be re-applied. Now it would seem that you can keep the test or staging environment in sync in a much more seamless fashion.

In addition to this, this tool also would seem to offer a good fail over solution for the CRM deployment. That is, by keeping a redundant CRM deployment (on site or in a remote location) that is kept in sync via the Instance Adapter, you now have the option of switching over to this redundant server as part of a disaster recovery plan. This is a feature that certain business (typically financial institutions) require (which seems particularly relevant right now as the East Coast braces for the onslaught of Hurricane Sandy).

What is not yet clear to me is how it will handle the following scenarios:

1. Deltas - If an update is made in the test environment will this be overwritten? Or will it require that the mirrored environment to be "read only"?
2. Frequency - How frequently the syncing occurs. Will this be configurable? Real time? Or only on demand? Such options factor into the tool being used as an effective disaster recovery option and also into requirements for bandwidth and such like.
3. Two-way - Can syncs go both ways? Almost certainly not going to be the case.

I am quite sure that this tool will not have the robustness of dedicated disaster recovery products such as  Double-Take (e.g. High Availability options). Or at least initially... But it definitely seems to be a tool that can be leveraged for optimizing test environments and perhaps to satisfy low to medium-end disaster recovery requirements without having to resort to a 3rd party (restoring a database is considered a very low end disaster recovery plan).

Time of course will tell as we learn more about this tool. To get a jump start on the installation and configuration of this tool you can review the detailed instructions provided in this PowerObjects blog posting.

Useful Dynamics CRM Utilities

I came across this post that contains a great reference list for a number of useful CRM 2011 free add-on utilities. It's good to have all this information summarized in one location for reference purposes so I felt it necessary to re-post:

http://everythingcrm.net/2012/08/16/revised-list-of-useful-dynamics-crm-2011-tools-utilities-scripts-controls

Others not yet appearing in the above listing:

• Web Resource Bulk Upload
• Ribbon Workbench Tool 
• Instance Adapter
• CRM Express Security Helper
• Form Query String Parameter Tool
• Ribbon Browser

Useful techniques (don't necessarily involve the use of a "tool"):

• Adding drop down menus to the ribbon
• CRM Live Purge

Another useful listing can be found here:

http://social.technet.microsoft.com/wiki/contents/articles/2490.microsoft-dynamics-crm-2011-development-resources-en-us.aspx

CRM Live Purge

So you've successfully conducted your Dynamics Sure Step Proof of Concept and your customer has decided to pull the trigger and implement CRM. Congratulations. You now quickly transition into implementation mode and the first step you need to do is purge your pilot data from your CRM environment. Or... you've successfully migrated your CRM data but you discover through testing that some data was deficient and you need to purge and reimport. Whatever the scenario your requirement right now is that you need to purge your data.

What is the best way of going about this in a CRM Live environment?

Well, technically this post does not only cover CRM Online - it can address purging in any CRM environment. However the reason why I'm addressing the CRM Live environment is because you can of course only purge data via the front end, 3rd party tool (e.g. Scribe) or using some programmatic solution that leverages the CRM APIs.

... And of course you should be doing the same in any environment, but let's just say that pragmatism sometimes sets in. For example, the size of the data makes the purge exercise a very slow one. So while I'm not going to go into it there of course "unsupported" ways of purging a CRM database in an on premise environment that are a thousand times more efficient than going via the API.

Anyway, back to the issue at hand - how do we go about purging? There are a number of ways:

1. Programmatic - Create a small .Net application. This should be pretty straight forward but requires a coded solution and you could run into problems with timeouts for large data sets.
2. 3rd Party e.g. Scribe - Build DTS's to purge the data. Again quite straight forward but assumes you have access to such a tool
3. Front end - you can of course use CRM's front end. However going from entity view to entity view and deleting that way would be highly inefficient both because you are limited to 250 rows per deletion and because you'd need to remember to repeat the same steps each time - assuming you need to purge more than once. So a more efficient way is to use the Bulk Record Deletion Tool. The remainder of this post will discuss using the Bulk Record Deletion as a purge tool.

The benefit of using the Bulk Record Deletion tool is that it essentially documents the steps required for the purge and it can subsequently easily be re-used to perform subsequent data purges. Below are the steps required to facilitate this:

Use the Bulk Deletion Wizard to delete all records from the entity in question (or you can limit this to a subset of records you wish to purge by filtering appropriately). Repeat for each entity you wish to purge.

Name the job appropriately and set a recurrence for 365 days. If you do not set a recurrence you will not be able to reuse the job at a later point in time so this is set only to facilitate reuse.

Now all your purge jobs will appear under the "Recurring Bulk Deletion System Jobs" and when you want to re-run the purge you can highlight all your purge jobs and select More Actions | Modify Recurrence to re-run the jobs immediately.

NB: It goes without saying that you need to create a very conspicuous reminder to cancel your purge jobs once you have cutover to production or else you might be in for a nasty surprise down the line... Use responsibly and at your own discretion.

Web Resource Utility for CRM Live

As previously described, the Web Resource Utility is a very useful tool for uploading well... web resources. But likely the most common web resources that you are going to want to bulk upload are image files that you will no doubt use to spruce up all your custom entities that you have added to your installation.

Getting this utility to work against CRM Live is perhaps a little bit unintuitive. So by way of example, let's say you're connecting to Contoso live environment using: https://contoso.crm.dynamics.com.

Then you're going to want to enter in the following connection information:

As illustrated:

• Organization - This is the organization shown under Developer Resources
• Domain - This is the first part of your URL i.e. contoso in our case

Adding drop down menus to the ribbon

Having briefly discussed the Ribbon Workbench Tool I thought I'd go about providing an example of how to go about adding a drop down menu on the CRM entity form.

Rather than keeping it simple, we'll dive straight into the deep-end and walk through an example of configuring a dynamic drop down menu. Chances are that if you are configuring something like this, you'll need to make it dynamic so it can interact with the elements on your form. This example builds on some other contributions that have been made.

We'll start off with the end result. Say we want to configure the ability to directly call a contact using either the business, mobile or home number present on the contact form. This solution should be dynamic in that it needs to pull the relevant numbers from the form and display them in a drop menu. Should one of the numbers not be present, then the corresponding menu option should not show.

Something like this:

The Ribbon Workbench Tool is a good starting point as it allows you to build the initial framework. We'll skip over that part and go ino the configuration of the ribbon component and the corresponding jscript. We'll do this at a fairly high level - use the screenshot below for reference.

1. In the FlyoutAnchor node make sure to specify the "PopulateDynamically = true" and create a reference to a command definition in the PopulateQueryCommand tag. This function is going to be responsible for creating the menu options.
2. Create the corresponding "Snt.DynamicMenu" Command Definition and reference the "DynamicMenu" jscript function (in an existing web resource jscript file). This simply calls the jscript function and passes in the context variable.
3. The "DynamicMenu" jscript function needs to construct and return the XML for populating the menu options. In this function, you can use all the conditional processing of jscript in order to construct the menu options to suit your implementation.
4. The Command tag in the body of the jscript XML should reference a valid Command Definition back in the RibbonDiffXml section. I'd recommend sticking to the names that have been used (unless you have more than one custom drop  down menu on your form in which case you'll need to distinguish).
5. Create the corresponding "Snt.OptionClicked Command Definition and...
6. reference the "OptionClicked" jscript function. This simply calls the jscript function and passes in the context variable.
7. The "OptionClicked" jscript function is used to handle the mouse click. You can just use the case statement to identify on which menu option the mouse was clicked and perform the necessary processing logic.

That's pretty much it. You can download the files referenced in the screenshots above from here.

Ribbon Workbench Tool

Forget the Visual Ribbon Editor, I have recently come across a more complete solution for configuring the application ribbon in CRM.

Introducing the Ribbon Workbench Tool which can be downloaded from here. This solution appears to support a lot more configuration options than the aforementioned solution. Suffice it to say, I think an image is the best way to encapsulate the myriad configuration options provided by this tool.

An instructional video is available on the product page.

Although I should say that for simple application ribbon modifications, the original Visual Ribbon Editor has proved to be a very simple tool to use so I can certainly still see myself using that option on occasion. But for scenarios involving more complex configuration requirements, such as the need to configure sub-menus (using "FlyoutAnchors") I think this is the tool that I'll be using.

Kudos to the developer.

CRM 2011 Visual Ribbon Editor

A while back I wrote up a few blog posts on how to go about adding buttons to the application ribbon. Since that time, a new tool called the "CRM 2011 Visual Ribbon Editor" has been released. This tool can be downloaded from codeplex.

This tool significantly simplifies the process of adding buttons to the ribbon by providing - as the name suggests - a graphical user interface for interacting with the CRM ribbon.

This tool doesn't completely eliminate the requirement of having to understand the various ribbon components and how to go about implementing Actions, Display and Enable Rules. However one of the biggest benefits is that it does all the legwork as far as formatting the underlying XML which can be a little tricky when trying to manually configure this option.

Simple requirements - such as adding a URL link to the ribbon - can indeed be performed entirely using this tool. However more complex requirements will still require manual intervention such as writing the jscript function that the Action, Enable or Display rule may call.

In addition to this, the author of this tool also mentions that it does not cover all configuration scenarios that the ribbon XML offers and lists a number of cases that are not supported on the codeplex home page. But even in those cases, this tool provides an excellent starting point by allowing for the basic XML structure to be created.

For example, I wanted to configure the "Phone Call" button such that it appears on the MainTab of a form. To do so, I pretty much copied the definition from the "Add Phone" under the Related tab.

Before this feature can work it is necessary to also pass a parameter to the jscript function (this can be viewed by downloading the application ribbon definitions) which can not be performed currently using this tool. At this point, all that is necessary is to export the entity ribbon in question, manually configure the XML to pass the parameter, and then re-import the updated application ribbon XML.

In short, I was able to use XML visual editor to configure 90% of the ribbon component and not have to worry too much about making sure that the XML structure respected the ribbon schema definition. The remaining 10% needed be configured manually by just updating the relevant parts within the already formatted XML structure. Very useful indeed.