Hardcore CRM: Using C# to modify an entity forms

I thought this year would start at a normal pace. Unfortunately that was wishful thinking. Right now we are in the middle of finishing up a large project. In this phase of the project the two products we developed have to integrate with a tailor made solution for the customer.

In the process of deploying the two managed solutions and the unmanaged custom solution (with the customer specific implementation) we sometime run into the problem that some customizations (e.g. form event scripts) are not always wired up correctly.

For that problem we wrote a manual with a large number of post configuration steps. Steps that describe which entity forms we have to check and what events should be wired up etc. A tedious process if you have to do it multiple times.

At the office we were discussing if we should build a tool that handles the post configuration steps for us automatically. Unfortunately our project manager didn’t think it was a good idea at this point of time (writing such a tool can cost a lot of time and time is the resource we are lacking at this moment).

The idea kept haunting me. Tonight I couldn’t resist and fired up my Visual Studio environment and I started to experiment.
On my CRM environment I have a solution with a simple form. On that form I wired two events (form onload, field onchange) to call a javascript function.

The last weeks I’ve been playing a lot with metadata, and this was the direction I headed to. I found out that with only a couple of lines of code I’m able to change the form definition by rewiring the events, submit it back to CRM and publish all modifications.

After reloading the page, the new events were in place.  How cool is that!


In the original form, the form used to call the function “alertMe” on the events (see green mark).



In the modified form, the form calls the function “alertYou” (see violet mark).


The code

This is the C# code that handles the modification.



In the Execute() function, I call the function “ModifyForm”. I pass in the logical name of the entity which form I want to modify.
In the ModifyForm() function, I send a request to CRM to get all the Filtered forms for the entity. The response I retrieve contains a collection of SystemForms.
I use the Id of the SystemForm to query the records in the systemforms entity (by using the LogicalName).

In the entity I retrieve, I have access to the XML definition of the Form. This XML definition happens to be in exact the same format as the FormXml in the Customizations.xml file.

In my case I made it simple and did a simple search and replace of the function name (alertMe) for a new function name (alertYou).  I update the entity (for some reason this is needed otherwise the modifications are not going to be published).

The next step I have to do is to publish the form’s xml. For that I have to use the <importexportxml></importexportxml> syntax (see customizations.xml) to create a PublishXmlRequest and execute it.

Finally when all changes have been imported, I have to do a final PublishAllXmlRequest, to publish all changes within CRM.

The next time I open the form, I get welcomed by a new alert message.

The CRM object model is great!