Useful Dynamics CRM Form Scripts #2
| In a recent article I described some of the main uses of Dynamics CRM form scripting, and contrasted it with a couple of other customization techniques (workflows, plug-ins) that can often be used to accomplish similar end results. | If you need to learn how to customize Dynamics CRM, topics like the one in this article are covered in my one-day live online training class, Customizing Dynamics CRM and the xRM Platform |
In this article I include three little JavaScript snippets I find a lot of use for, each of which can be applied in lots of different scenarios.
Form Script 2.1: Make sure Opportunity Estimated Close Dates are Up-to-Date!
I like things nice and simple. Plus, I hate it when I look at a view of open opportunities in Dynamics CRM and most of the “Est. Close Date” values are before today’s date! JavaScript like the following, in the onSave event of the opportunity form, satisfies the “simple” criteria and helps out with the overdue opportunities syndrome. It doesn’t solve it completely, since opportunity records might be created and saved without using the opportunity form. (e.g., by importing records or by workflows).
But it definitely helps!
var currentdate = new Date();
if (currentdate > crmForm.all.estimatedclosedate.DataValue)
{
alert ('Estimated Close Date must be greater than today\'s date!');
crmForm.all.estimatedclosedate.SetFocus();
event.returnValue = false;
return false;
}
Form Script 2.2: Use ‘additionalparams’ to Filter Lookups
Dynamics CRM doesn’t filter lookups by default. For example, it might seem a little odd at first that the “Primary Contact” lookup on the account form displays and lets you select from ALL contact records, rather than only the ones associated with the current account record. If you want to filter lookup fields along these lines, you can use the ‘additionalparams’ parameter to do it.
Here’s an example of how to implement a filtered lookup for primary contact on the account form, like I described above.
First, place the following code into the OnLoad event of account:
var CRM_FORM_TYPE_CREATE = 1; var CRM_FORM_TYPE_UPDATE = 2;
switch (crmForm.FormType)
{
case CRM_FORM_TYPE_CREATE:
break;
case CRM_FORM_TYPE_UPDATE:
var accountname = crmForm.all.name.DataValue;
crmForm.all.primarycontactid.additionalparams = 'search=' + accountname;
break;
}
FilterLookup = function(source, target)
{
var name = source.DataValue;
target.additionalparams = 'search=' + name;
}
Second, put this one-liner in the OnSave event of the Account form:
FilterLookup(crmForm.all.name, crmForm.all.primarycontactid);
This is interesting, as it shows how you can place a re-usable function (FilterLookup, in this case) in the OnLoad event, and reference it from elsewhere on the form, passing the “source” and “target” values in to it.
Third, you need to customize the “Contacts Lookup” view for the Contact entity, adding the Parent Account field as an additional ”Find Column”. This is easy to overlook, and a little hard to track down if you forget to do it. If you do NOT add Parent Account as a Find Column, the code will work fine, and when you click the Search button on Primary Contact you’ll see the account name in the lookup…but it won’t locate any contact records for you since it’s not a Find Column!
Form Script 2.3: A Little More on “Calculated” Fields
In a previous article, I wrote a little bit on how you can create what’s effectively a “calculated field” on a Dynamics CRM form. For example, consider the following form, open in the form designer:
These are all money fields, and we want Catering + Room rental + Travel to equal Total. To accomplish this, you could put code like the following in the onChange events of each of the three data entry fields (catering, room rental and travel):
crmForm.all.new_total.DataValue = crmForm.all.new_catering.DataValue + crmForm.all.new_travel.DataValue + crmForm.all.new_roomrental.DataValue;
That gets a little tedious, however, and especially if you have 57 data entry fields contributing to the sum and you then have to add a 58th, requiring you to add the onChange event code to your new field plus 57 others! So instead, place the calculation code (the previous snippet) behind the onChange event of the calculted field (in this case, Total), and put the same, never-changing snippet behind every data entry field contributing to the calculated field:
crmForm.all.new_total.FireOnChange();
If you do it like that, you only have to update one script. Much better that way!


Larry Bradley Said,
June 13, 2010 @ 9:01 pm
Richard,
Your information has been very helpful. I’m ordering your workflow book tomorrow. I have a question about form scripting with dates. I’m eager to learn scripting for the CRM forms as I realize the potential. Our company uses CRM Online. I have a custom entity called Projects. This is for custom vehicles we order for customers. There is a date field called new_shipmentforcast. I need to populate another field called new_daystillshipment with the number of days which is essentially Today – Shipment Forcast. I don’t know how to form the proper syntax to make this work. Also if you could point me to a resource book or on JScript for use with CRM that would be great
Richard Knudson Said,
June 15, 2010 @ 11:29 am
Hi Larry,
OK, it took me a couple of days but I think I came up with a reasonbly good explanation of how that works. See what you think: http://www.dynamicscrmtrickbag.com/2010/06/15/useful-form-scripts-4/
Thanks for reading!
Jij Said,
August 25, 2010 @ 4:55 am
Hello Richard,
Have been following your blog entries for quite a long time now. Thanks for all of those.
I was looking at your code on filtered lookups.
I tried to use this code on a form, where I had two lookups, ‘country’ and ’state’. And I was able to filter values on the 2nd lookup based on the value selected on the 1st lookup. That works great.
But when the user clicks on the ’state’ lookup icon, the user also sees the ‘Country’ value on the top right of the ’state’ lookup dialog; and so can still go and change the country name.
Do you know of any trick that disallows the user from changing the ‘filter value’; or hides/disables this text box for the end user?
Thank You
Yash Patel Said,
September 3, 2010 @ 9:14 am
Thanks for posting the scipts online Richard
I try to use your script for “Make sure Opportunity Estimated Close Dates are Up-to-Date!”
It works great but it is also giving ths same pop – up message when creating the new opportunities. Users are finding this is annoying
Any modification to this script can help eliminating this message for the new opportunities?
Richard Knudson Said,
September 3, 2010 @ 9:46 am
Hi Yash,
It depends on the business rules you want to enforce. For example, the following code will only check the condition if there’s something in the date field:
if (crmForm.all.estimatedclosedate.DataValue != null)
{
var currentdate = new Date();
if (currentdate > crmForm.all.estimatedclosedate.DataValue)
{
alert (’Estimated Close Date must be greater than today\’s date!’);
crmForm.all.estimatedclosedate.SetFocus();
event.returnValue = false;
return false;
}
}
But if you really want them to be able to enter an old date when a new record is created, you can embed the code inside a switch block like the one I show in 2.2 in the article. that would make it so they can save an outdated opportunity when a record is first created, but not when it’s being updated. That seems like odd logic, so I’m guessing it’s really the null value you want to check for.
Thanks for reading!
Domenic Said,
September 8, 2010 @ 2:17 pm
Form Script 2.2: Use ‘additionalparams’ to Filter Lookups
I had already implemented this script a while back but have come across a few glitches with it.
If the name contains the ampersand (&) or the pound sign (#), this will not work. (possibly other characters as well) You need to replace these characters with their ascii equivalents.
var sCompany = crmForm.all.name.value;
sCompany = sCompany.replace(”&”, “%26″);
sCompany = sCompany.replace(”#”, “%23″);
crmForm.all.primarycontactid.additionalparams = ’search=’ + sCompany;
There’s still a problem I haven’t solved. If I have 2 companies: (1) Some_Local #24 and (2) Some_Local #246, when I do the search for Local #24, I also get the contacts for Local #246. If I do a search for company Local #246, all is well.
Apparently it wildcards the end of the name.
Do you have any idea how to get around this wildcarding and force an exact lookup on the name?
Thanks for your time and consideration.
Domenic
Yash Patel Said,
September 14, 2010 @ 9:02 am
Hi Richard,
Your new script helped with the new opportunity but now users started complaining why they can’t close opportunity record even though Est. Close date is today’s date. When they won opportunity, they would like to close it as est. close date as today’s date.
Any coding change can accomplish this?
Thanks a lot for all your help
Mike DeBaise Said,
September 23, 2010 @ 10:26 am
I can’t get the FormScript 2.3 to work. I have it setup exactly as you do with my attributes. I am using data from a picklist with either a “0″ or a “1″. The form basically is a QT for our product assembly and indicates a score for what was included. If an item was included in the assembly it gets a “1″ if it wasn’t included it gets a “0″. There are multiple sections I hope to get this to work for where it totals each section. The form seems like it’s working but no totals are displayed in the “totals” field. Here is what I have;
(In each attribute I wish to add)
OnChange: crmForm.all.new_docstotal.FireOnChange();
(In the total attribute)
OnChange: crmForm.all.new_docstotal.DataValue = crmForm.all.new_docsvehiclemanualcomplete.DataValue + crmForm.all.new_docswarrantyinformationinbook.DataValue + crmForm.all.new_docsfastlanedomedecalspresent.DataValue + crmForm.all.new_docsfastlanecommandnetmanualincluded.DataValue + crmForm.all.new_docsaddedschematicspresent.DataValue + crmForm.all.new_docsproductionplatecompletedinstalled.DataValue;
(In the Form Properties)
OnLoad: crmForm.all.new_docstotal.Disabled = true;
OnSave: crmForm.all.new_docstotal.ForceSubmit = true;
Can you see what I might be doing wrong?
Re-usable JScript Libraries in Dynamics CRM 2011 - Richard Knudson’s Microsoft Dynamics CRM Trick Bag - CRM Technical Blogs - Microsoft Dynamics Community Said,
December 24, 2010 @ 1:18 pm
[...] example, check out the code required to create a filtered lookup in CRM 4.0 and then compare it to the no-code-form-editor-only approach in CRM 2011 (the latter example is [...]