Saratoga Technologies Microsoft CRM Blog

I got this idea from the Microsoft CRM team blog and their guest blogger David Jennaway. The idea of acceptance and user reporting for CRM is really basic, but it provides a trackable way to determine if users are accessing the system. Here is the article.

 http://blogs.msdn.com/crm/archive/2009/04/08/crm-usage-reporting-unleashed.aspx

 A couple things that i found in the article to ‘tweak’ was defiantely adding a couple check constraints onto the SQL log table that you will be using this for. In my case there are quite a few users generating activity and that would be a very large file. Thank goodness for sql table compression in 2008 right… we will see.

If you haven’t created a check constraint before it is really easy, and you will save your tables from a bunch of useless rows of data. Here is a quick example below.

USE [CRMACCEPTANCE] 

ALTER TABLE [dbo].[inetlog] WITH NOCHECK ADD CONSTRAINT [CK_inetlog_username] CHECK (([username]<>‘MEDTECH\scribe’)) 

This is basically because i use scribe integration that is always writing rows into the database and these could cause significant storage use during the period of a month.

For those of you who are attempting to migrate Microsoft Dynamics CRM services to another remote server to help increase your I/O, performance or for whatever reason you like, you may find frustrated during this process.

 There are a few things that you need to do first to ensure that you have a smooth upgrade. First off i would definately check out the following article to ensure that a path that is defined is the easiest for the job.

 http://support.microsoft.com/kb/952934

 This will assist with moving your database of Microsoft CRM 4, and reporting services. However, there is also a few steps that are not included in this document.

Just make sure that after you deploy your reporting services reports to the new migrated server that you have also double checked the login on the mscrm datasource in the reportserver directory.

You can get errors that you will not be able to connect to CRM datasource and more. Turns out that after a couple of hours fighting with checking IIS security, SQL Service accounts, CRM deployment settings, SRSS groups and regedit settings that it turns out this is the most often overlooked.

So simple, but it can also be very aggrivating. Till next time!

Today we came across the great unsupported customization requests of Microsoft Dynamics CRM 3 which was a customized and filtered lookup box for Microsoft Dynamics CRM 4.0.

 Although lookup boxes are much easier to generate natively in Microsoft CRM 4.0 you just need to create a N:1 relationship to whatever entity you want your lookup box to pull information for.

For example on the opportunities entity you may want to not only have “potential customer”, but also have the ability to show a list of contacts to choose from that are specific to the selected customer. This is simply known as a filtered lookup, and here is an easy way to accomplish it.

After you have completed your many to one relationship (if one doesn’t already exist) on your customized entity you can easily with javascript filter the second lookup.

 You will first have to add the following onload event to your entities form.

document.FilterLookup = function(source, target)
{
    if (IsNull(source) || IsNull(target)) { return; }

    target.additionalparams = ’search=’ + name;
}

Then on the onchange event of your attribute (in our case potential customer) you will have to trigger the filter function as in the example below, so that it will in fact also filter the second lookup field on the form as shown in the Custom Lookup Filter Image.

// If company is defined pre-filter lookup with customers
document.FilterLookup(crmForm.all.customerid, crmForm.all.sti_contact_opp_linkid);

 This also works best if you additionally copy the script to the onload of the form as well, this is so that if the user decides to change the existing contact to another contact it will still function as originally intended.