Two events are global in nature for all forms: the onLoad event and the onSave event.
The onLoad event fires
after the form has completed loading, and is commonly used to send an
alert to the user, disable fields, or modify field values.
The onSave event fires
when the Save or Save and Close buttons are accessed, and it is
important to note that it fires regardless of whether data on the form
has been changed. This event is commonly used to validate an entry
because the onSave event can cancel the save operation.
addition to the form events, the onChange event is available for every
field on a CRM form. To fire the onChange event, the field that has the
event attached to it must have its value changed, and it must lose the
focus (by the user selecting or tabbing elsewhere on the form).
One of the easiest ways to
perform an integration to an existing Microsoft Dynamics CRM deployment
(both hosted or On Premise) is to use IFrames.
IFrames are “inline
frames or windowless inline floating frames” and provide an easy
mechanism for integrating data, because they can exist free form or
easily pass data through them to the underlying source.
Although this is one of the
easiest ways to extend Microsoft Dynamics CRM, it does have one major
limitation: You must have a connection to the underlying application.
Therefore, if you’re working offline or remotely and your application
requires a VPN to access (because it is on your local intranet), you
should consider an alternative solution.
In addition, there is no built-in CRM reporting on any of the IFrame application data.
Microsoft Dynamics CRM
Online supports the creation of IFrames, but it doesn’t support the
hosting of the underlying page. Therefore, you must leverage your own
(or someone else’s) hosting services for an integration with CRM Online.
To create an IFrame, open the Form Designer, select Add an IFrame, and complete the information required. Figure 1 shows the basic information of a sample IFrame.
Figure 1. Microsoft Dynamics CRM IFrame creation example.
You want to pay special attention to two areas:
The first option (Pass
Record Object-Type Code and Unique Identifier as Parameters) is
actually six parameters in Microsoft Dynamics CRM 4.0 (only two in the
The typename is the
name of the entity (Account, Contact, and so on). For custom entities,
the customization prefix is prepended (normally new_; but if you’ve
changed the customization prefix, which is always a good practice, that
will be your prefix, followed by the entity name. For example, if we
create a new entity called ProjectDescriptions, the typename will equal
new_ProjectDescriptions or wf_ProjectDescriptions).
The type is an integer that uniquely identifies the entity. Table 1 shows the object codes for CRM.
Table 1. Microsoft Dynamics CRM Object Type Codes
|Incident||112|| || |
id is the ObjectId, which is the unique identifier or GUID. This value
is displayed in the URL of every form in the system (and is null until
the form is created).
Figure 2 shows a GUID of a sample account in the address bar.
Figure 2. Microsoft Dynamics CRM GUID sample.
The orgname is the unique name of the organization, the UserLCID is the language code in use by the current user, and the OrgLCID is the language code that represents the base language for the organization.
Both the UserLCID and the OrgLCID are four-digit codes.
As counterintuitive as it
sounds, best practices usually call for using the entity name (for
example, Account, Contact) rather than the type code. The reason for
this is that entity codes may differ between one Microsoft Dynamics CRM
installation and another.
Consider this illustration of the effect that passing these parameters has. When the URL referenced in Figure 3.7
is called without Pass Record Object-Type Code and Unique Identifier as
Parameters being selected, the following URL is called from the form:
When the Pass Record Parameters option is selected, the following URL is called from the form:
Table 1 shows the object codes for CRM.
You can readily see how
powerful and easy it is to create specific information related to the
selected record on the underlying application using this information.
The second option,
Restrict Cross-Frame Scripting, is selected by default to help protect
the integrity of the CRM application. The effect of this selection is to
basically place the application in the IFrame in restricted mode (as
defined in Internet Explorer).
This option is unselected when you want to have a level of interaction between the application that is in the IFrame and CRM.
The restriction also applies to applications contained within the IFrame that may need to read from the CRM application.
An example of this is a custom
application that performs a background check on an account for
credit-worthiness. When the credit check comes back, the custom
application could reference a Boolean value on the account form and set
the value of Background Check Cleared equal to true.
The CRM Outlook
laptop client has higher security restrictions in place, and in some
cases it is not possible to programmatically update fields as described.
Be sure to thoroughly test your solution in all environments before
rolling out to production.