Upon opening a report with a pre-filter, you expect to be presented with a query builder that will allow you to search for accounts, contacts or other CRM entity by location, owner, or any other field on the respective entity. Something that looks like this:

What do you do then, when instead you see this (and only this. Nothing's loading. It's "Done."): 

The pre-filter is blank and there doesn't seem to be an error anywhere. Attempting to "Edit the default filter..." results in the same empty, blue screen. In this case, the filter was loading correctly in the past, but now something is clearly wrong.

Let's go back to what the pre-filted should look like. It should allow users to filter Accounts by specific Account, Address 1, Category, or a custom attribute called Rating. After minutes of trying to connect the mental dots, I realized that I intentionally deleted one of the Rating attribute because it was no longer needed. Ah ha!

Turns out that, although CRM will not allow you to delete attributes that are on a published form, you are able to delete an attribute that is used on a report pre-filter. However, the fact that the attribute has been deleted keeps the pre-filter from being rendered.

To fix this, there are a couple of options.

If you know the name of the attribute the filter can't find, you can simply create a dummy attribute with that name, publish the entity with your attribute, edit the report's default filter and remove the dummy attribute from the report pre-filtered. Delete the dummy attribute from the entity and all it well again.

If you don't know the name of the attribute or would just like an excuse to dig around in the database, you can also edit the report filter's XML.

In your organization's CRM database, there is a table called ReportBase. Opening that table, you'll find all of the versions of the reports that are available or were available. To figure out which report you're working with, grab the GUID from the URL of the report pre-filter and query the ReportBase table for the record with that ReportId. That record will have a DefaultFilter field, which contains the pre-filter's XML. Once formatted correctly, it should look something like this:

To get the my report pre-filter to render, I can remove the element specifying the deleted attribute as a condition, in this case the line containing "new_rating." Once I've done that I can simply copy the XML back into the DefaultFilter field for that report and the pre-filter will render.

Although this fix is a little in-depth and should only be attempted by those very comfortable with the CRM database, it is a workaround if you're in a bind and do not want to have to re-create a report.

One of the least published example of CRM code is deactivating an entity, probably because it's not used as often as creating, updating or retrieving entities.  Below is an example I've used on several occasions to deactivate an entity:

public void DeactivateEntity(Guid entityId)

{

//variable initialization

            SetStateDynamicEntityRequest deactivateReq = new SetStateDynamicEntityRequest();   

            //deactivate the cloned assignment

            deactivateReq = new SetStateDynamicEntityRequest();

            deactivateReq.State = "Inactive";

            deactivateReq.Status = 2;

            deactivateReq.Entity = new Moniker();

            deactivateReq.Entity.Name = <entity name>

            deactivateReq.Entity.Id = entityId;

//execute the deactivation request

            service.Execute(deactivateReq);

}

I have seen numerous requests on other blogs about sample code to on how to update entities in CRM.  One way is to use the CRM web service to update business entities, however by doing so, you're only limited to out-of-the-box entities with system attributes.  To retrieve anything more "dynamic," you'll have to employ other methods.  Please remember that in order to update any record, you must have the proper permissions on that entity.

Below is a code example of how to update a record:

public void UpdateEntity(ICrmService service)

{

//variable initialization

            DynamicEntity entity = new DynamicEntity();                                                     //target entity to update

            TargetUpdateDynamic targetUpdate = new TargetUpdateDynamic();      //used to update entity

            UpdateRequest updateRequest = new UpdateRequest();                            //request to update entity

entity.Name = <entity name>

//add the properties you want to update on the entity

entity.Properties.Add(<property1>);

entity.Properties.Add(<property2>);

entity.Properties.Add(<property3>);

//set the target to update, and the request to update for

targetUpdate.Entity = entity;

updateRequest.Target = targetUpdate;

//execute the update request

service.Execute(updateRequest);

}

Here's a simple JavaScript customization to enable an e-mail field, once filled in, have a user double-click it and open your default e-mail client with the address in the "To" field.

if(crmForm.FormType == 1 || crmForm.FormType == 2)

{

                crmForm.all.emailaddress1.ondblclick = function()

                {

                                var email = crmForm.all.emailaddress1.DataValue;

                                if ((email != null) && (email.length > 0))

                                {

                                     window.navigate("mailto:" + email);

                                }

                }

}

Now if you want to make CRM open an e-mail activity instead of the default e-mail client, you can use the following code (when sending the email, CRM will use email address 1 regardless of what field was dobule clicked):

if(crmForm.FormType == 1 || crmForm.FormType == 2)

{

                crmForm.all.emailaddress1.ondblclick = function()

                {

                                var email = crmForm.all.emailaddress1.DataValue;

                                if ((email != null) && (email.length > 0))

                                {

                                     window.execScript(locAddActTo(4202))

                                }

                }

}

There have been numerous requests on other blogs about sample code to on how to create entities in CRM.  One way is to use the CRM web service to create business entities, however by doing so, you're only limited to out-of-the-box entities with system attributes.  To retrieve anything more "dynamic," you'll have to employ other methods.  Please remember that in order to create any record, you must have the proper permissions on that entity.

Below is a code example of how to create a record using dynamic entities:

public void CreateEntity(ICrmService service)

{

//variable initialization

DynamicEntity entity = new DynamicEntity();                                                 //target entity to update

TargetCreateDynamic targetCreate = new TargetCreateDynamic();          //used to update entity

CreateRequest createRequest = new CreateRequest();                                //request to create entity

entity.Name = <entity name>

//add the properties                   

entity.Properties.Add(<property>);

Entity.Properties.Add(<property>);

//set the target to update, and the request to update for

targetCreate.Entity = entity;

createRequest.Target = targetCreate;

//execute the update request

service.Execute(createRequest);

}

Hope this helps, happy coding!

Whether it's developing CRM plug-ins, custom workflow activities, or writing stored procedures against the CRM database, the most useful tool I've used is the Microsoft Visual Studio Debugger.  The debugger allows developers to step through the code for the above mentioned scenarios and has saved me hours! 

Microsoft has phenomenal documentation on how to setup remote debugging:

http://msdn.microsoft.com/en-us/library/bt727f1t.aspx

The biggest issues I've had trying to setup the debugger has always been with permissions.   I would recommend paying especially close attention to this section.  The next biggest issue I had was trying to attach the debugger to a running process: http://msdn.microsoft.com/en-us/library/c6wf8e4z.aspx

Once you've setup Visual Studio debugger, you can attach the following processes for the following CRM components:

1. For plug-ins, attach the debugger to the w3wp.exe process.
2. For custom workflow activities, attach the debugger to MSCRMAsyncService.exe
3. For stored procedures, attach the debugger to sqlserver.exe

Once the debugger has been attached, you must set a breakpoint in the code (either the .NET or T-SQL code).  After the breakpoint is set, to test, do the following:

1. For plug-ins, login to CRM and execute actions that will trigger the plug-in, such as create/update/assign a record.
2. For custom workflow activities, login to CRM and perform actions that will trigger the workflow.  With this, being that it's an asynchronous service, you'll have to wait until that service runs, and then Visual Studio will let you step through the code.
3. For the stored procedure, just execute the stored procedure in Visual Studio and it will go right to the breakpoint.

I hope this post will help CRM developers save time and effort.  I use the debugger every time I develop now to test and it's saved me tremendous amount of maintenance time and effort after the code has been deployed.  Happy debugging!

The CRM 4.0 Plug-in registration tool is Microsoft's tool to register any plug-in developed for CRM 4.0 and callouts that were developed for CRM 3.0, but need to be upgraded to 4.0.  In this article, I'd like to take a step by step walkthrough of the tool including any interesting facts or issues I've run into during this process.  Those will highlighted in the "NOTE" section.

To download the tool, please visit: http://code.msdn.microsoft.com/crmplugin for the latest version.  The tool also comes packaged when you download the CRM 4.0 SDK, which you can do from: http://www.microsoft.com/DOWNLOADS/details.aspx?familyid=82E632A7-FAF9-41E0-8EC1-A2662AAE9DFB&displaylang=en. 

Building The Plug-in Registration Tool

Either way, the download will contain Visual Studio project files that will need to be built.  Mitch Kett in his blog has outlined how to do this: http://www.crowehorwath.com/cs/blogs/crm/archive/2008/03/19/incorporating-custom-entities-into-a-plugin-revised.aspx. 

**NOTE:  The CRM SDK provides great information on what each service provides for the user:

The CRM Web service provides strongly typed access to all entities in Microsoft Dynamics CRM, including custom entities and attributes. This Web service also allows execution of all supported operations, including those with built-in business logic as well as specialized operations. It provides a valid Web Services Description Language (WSDL) that is dynamically generated on the server to include the latest customizations and provides a single endpoint for your code.

The Discovery Web service is a mechanism to find the correct CrmService endpoint for your organization or to obtain a CRM ticket for Internet-facing deployment (IFD) or for Microsoft Dynamics CRM Online.

The Metadata Web service provides methods to read and write the metadata for an organization. This includes the definitions for entities, attributes, and relationships.**

**NOTE:  If you don't place the assembly files mentioned in step (8) of Mitch's instructions, when you go to run the plug-in registration tool, you might get an error: "...Could Not Find Dependency…"**

Using The Plug-in Registration Tool

1. You can launch the tool by either running the executable built from the project mentioned in the steps above, or if you've configured Visual Studio with a shortcut, you can launch it from that menu.

Here is a great article that illustrates how to publish Microsoft CRM 4.0 through ISA Server 2006: http://blogs.technet.com/isablog/archive/2008/07/23/publishing-microsoft-crm-4-0-through-isa-server-2006.aspx

The article is broken up into the following sections:

1. Adjusting CRM Server For External Publishing
1. General Considerations
2. IFD Configuraiton

1. Configuring ISA Server 2006 Web publishing rule
2. Troubleshooting Tips

For those who need some information on Microsoft ISA Server: http://en.wikipedia.org/wiki/ISA_Server

Below are some very useful links on standards for Microsoft CRM and SQL Server Reporting Services:

http://www.ssw.com.au/ssw/Standards/Rules/RulestoBetterMicrosoftCRM.aspx

http://www.ssw.com.au/ssw/Standards/Rules/RulesToBetterSQLReportingServices.aspx

Enjoy!

Another common question I see in blogs from users are is there a way to add filtered lookups?  That is only allow users to "lookup" certain records that related to that particular one.  Here's a real life example:

Say you have an account that has a 1:N parental relationship with entity A.  Now let's say there's another entity B that has N:1 referential relationships with both account, and entity A.  There is a way on entity B so that after you select, on the lookup, a record of the account you want to relate to it, to filter the second lookup of entity A to only those related to the account you just selected.  i.e.

Parental Relationship

Account --> Entity A

Referential Relationship

Entity B -- Account

Entity B -- Entity A

With simple JavaScript, when a user selects the lookup value for the account, the lookup for Entity A can be filtered to point to only those entity A's that are related to the account you just chose.  Here's the code to place on the form of Entity B:

crmForm.all.<lookup field for entity A>.additionalparams = 'search=' + encodeURIComponent(crmForm.all.<lookup field for account>.DataValue[0].name);

That's it!  Simple, yet effective.

There have been numerous requests on other blogs about sample code to on how to retrieve entities in CRM.  One way is to use the CRM web service to retrieve business entities, however by doing so, you're only limited to out-of-the-box entities with system attributes.  To retrieve anything more "dynamic," you'll have to employ other methods.  Please remember that in order to retrieve any record, you must have the proper permissions on that entity.

Below is a code example of how to retrieve a record with an id using dynamic entity retrieve:

 public DynamicEntity RetrieveEntity()

{

            //variable initialization    

            TargetRetrieveDynamic target = new TargetRetrieveDynamic();        

            RetrieveRequest retrieveRequest = new RetrieveRequest();           

            RetrieveResponse retrieveResponse = null;                                      

DynamicEntity entity = null;                                     

            target.EntityName = <name of entity here>

            target.EntityId = <id of entity here>

            //initialize request parameters

            retrieveRequest.ColumnSet = new AllColumns();

            retrieveRequest.ReturnDynamicEntities = true;

            retrieveRequest.Target = target;

            //build the response object

            retrieveResponse = (RetrieveResponse)GetCrmService().Execute(retrieveRequest);

            //retrieve the service order item from the response

            entity = (DynamicEntity)retrieveResponse.BusinessEntity;

            return entity;

}

The above example is a simple one, but the example below retrieves all contacts that have an account id = some id, and also retrieve the records with only a certain attributes.  This is probably a more robust example encompassing many retrieval options:

private ArrayList RetrieveMultipleContacts(ICrmService crmService, Guid parentAccountId)

{

//variable initialization

ConditionExpression condition = new ConditionBLOCKED EXPRESSION;

FilterExpression filter = new FilterBLOCKED EXPRESSION;

QueryExpression query = new QueryBLOCKED EXPRESSION;

RetrieveMultipleRequest request = new RetrieveMultipleRequest();

ColumnSet cols = new ColumnSet();

RetrieveMultipleResponse response = null;

ArrayList contacts = new ArrayList();

//Set the condition for retrieval

condition.AttributeName = "parentcustomerid";

condition.Operator = ConditionOperator.Equal;

condition.Values = new string[] { parentAccountId.ToString() };

//Set the properties of the filter.

filter.FilterOperator = LogicalOperator.And;

filter.AddCondition(condition);

//Set the attributes needed to be returned.  NOTE: The CRM Sdk has an erroneous example

//of how to set the attributes for retrieval.

cols.Attributes.Add("address1_line1");

cols.Attributes.Add("address1_line2");

cols.Attributes.Add("address1_line3");

cols.Attributes.Add("address1_city");

cols.Attributes.Add("address1_stateorprovince");

cols.Attributes.Add("address1_postalcode");

cols.Attributes.Add("address1_country");

cols.Attributes.Add("telephone1");

cols.Attributes.Add("fax");

//Set the properties of the QueryExpression object.

query.EntityName = EntityName.contact.ToString();

query.ColumnSet = cols;

query.Criteria = filter;

//Set the query for the request and set the flag to return

//dynamic entities

request.Query = query;

//retrieve the contacts

response = (RetrieveMultipleResponse)crmService.Execute(request);

foreach (BusinessEntity cont in response.BusinessEntityCollection.BusinessEntities)

{

contacts.Add(cont);

}

return contacts;

}

I hope these examples help someone, happy coding!

In CRM, when creating appointments, you can set the status to Open or Scheduled.  But why would a user set the status to one or the other?

According to the SDK, the status and state codes are different:

For CRM Outlook users, the only real difference seems to be the scheduling.  When other users look at your calendar during this time period, if the appointment was marked Open, the time block will be marked as "tentative."  If the appointment was marked Scheduled, the time will show up as "busy" in Outlook.

There's an excellent post on the MSDN CRM blog on how to create an audit trail using the CRM 4.0 workflow.  I've had numerous customer requests for an audit trail of entities when a field changes.  Clients want to know when certain fields change, and who made the change. 

The MSDN post gives a great example of using out of the box CRM workflow functionality to meet their needs: http://blogs.msdn.com/crm/archive/2008/04/10/using-workflow-to-maintain-an-audit-log.aspx.

Business Requirement

I recently had a requirement where if an account's address was updated, all associated contact's addresses needed to be updated as well.  Likewise, if a contact gets re-associated to another account, i.e. the parentcustomerid field gets changed, then update that contact's address.

Initial Development

I thought we could use a CRM custom workflow activity to handle this because it gives the business user the ability to configure the workflow.   So I created two separate workflows that would call a custom workflow activity assembly.  The trigger to call the account workflow was if any of the address attributes changed, and for contact was if the parentcustomerid was set/changed.

The assembly itself first checked the workflow context to see what the primary entity was (to handle being called from the account or contact workflow).  Then the required business logic was performed, and the CRM web service update was called to update the contact entity.

Test Results

After I registered the assembly and started unit testing, it looked as if everything worked. Then looking at the history of workflows for the test contact record, I noticed about six entries for the workflow I just configured.  Then I used a VPC and tested the assembly by using Visual Studio debugger, attaching it to the CRM Asynchronous  Service process,  and found that there was an infinite loop occurring.

When the contact record was re-associated to another account, the workflow kicked off and executed the custom assembly.  Within the code, it set only the address properties on that record and then called the CRM service update method.  Right after that update was made, a new workflow instance was called again.  To make sure, I commented out the update call in the code and…no more loops!

Final Thoughts

Some technologies have flags for attributes to determine if that particular attribute has been updated or not.  When the CRM web service update was called, even though I only set the address fields, it seems to "flag" that all attributes have been updated.  Either that, or the workflow conditions were never checked. 

I even tried to add some sort of check to make sure even if the workflow was called the code wasn't executed.  However, unlike plug-ins, workflows don't have functionality to check the values before and after an update.  I also tried putting a global counter to update after the first run, and check if the method was called again.  However, the entire workflow was called again, which created another instance of the class, thus the counter idea didn't work.

Solution

I finally ended up using a plug-in, which you can configure to run asynchronously if you heart desires.  In the future, I now know that a workflow should not be setup to call a custom assembly that updates that same record.  The CRM web service update will cause infinite loops, and is better handled via a plug-in.

When performing a data integration or migration into CRM, it is very common to create a .Net application that transforms the data, then pushes the records into CRM using the WebServices.  At times, however, the load of data being pushed to IIS can be more than is acceptable to the default settings in an IIS implementation.  At these high load times, the server might post an error stating "Only one usage of each socket address (protocol/network address/port) is normally permitted (typically under load)."

What is happening, is that connections are being repeatedly opened and closed on the webserver.  When a connection is closed, the connection goes into a TIME_WAIT state for 240 seconds.  This is the default setting.  In this case, the IP being used is typically fixed, which means that the variable is the local port.  By default ports 1024-5000 are available to be used, which means that using default setting you have approximately 4000 ports to be used during a 4 minute span (240 seconds).  So if your code is making more than 16 webservice calls per second, you will exhaust all of the available ports!

 To fix this problem, you can make 2 different registry changes on the CRM Application Server.

1. Increase the dynamic port range.  As stated above, the default is 5000 but this can be raised up to 65534.
• Using Regedit, navigate to  HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\Parameters\MaxUserPort (if this key does not exist, create it as DWORD value)
• Set the value to 65534, or a value of your choice
2. Reduce the amount of time that the connection is in a TIME_WAIT state.
• Using Regedit, navigate to  HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\Parameters\TCPTimedWaitDelay (if this key does not exist, create it as DWORD value)
• Set the value to 30