How to show Javascript alerts with appropriate alert messages

So often in CRM, users need to be alerted of their actions. For example, a typical alert might be a message that warns you when a user attempts to enter a text string into a numeric field.

Using the alert() method, a message is usually displayed in a pop-up window. This type of alert method does not require any in-depth response from users, who will simply acknowledge it by clicking the OK button.

Microsoft CRM Pop-Up Message 1

With Microsoft Dynamics CRM 2013 and 2015, Microsoft Dynamics CRM has continued to improve the user experience by introducing a flattened interface so to speak.

This approach focuses on removing excessive clicks and flattening out pop-up windowsfound in the previous version of Dynamics CRM.

With that in mind, using an alert method that requires a response from users seems to contradict the flattening approach.

At the same time, Dynamics CRM 2013 and 2015 introduced new alert methods:setFormNotification and setNotification.

These two methods display messages on the form instead of on a pop-up window, and require no clicking from users.

The Classic CRM Alert Method Versus the New Improved CRM Alert

In this article, I am going to demonstrate how the new alert methods are different from the classic one, and how they can be used.

The example here is a credit card form where credit card numbers and a CVV codes were to be validated. In the previous version of Dynamics CRM, using the classic alert() method, users are typically notified of errors one by one and users have to acknowledge them by clicking OK.

Microsoft CRM Pop-Up Message 2

Microsoft CRM Pop-Up Message 3

Of course this alert method can be slightly improved by displaying the error messages in one single alert, thus reducing the number of pop-ups and clicks to one. But still users have to make the effort clicking the OK button.

Microsoft CRM Pop-Up Message 4

Eliminating the Mouse Clicks on the Notifications in Dynamics CRM

In Dynamics CRM 2013 or 2015, mouse click(s) can be completely eliminated by using setFormNotification that displays message on the form header area. And depending on the nature of messages, they can be categorized as information, error and warning.

  • Xrm.Page.ui.setFormNotification(‘Please fix the following error(s):’, ‘INFORMATION’,);
  • Xrm.Page.ui.setFormNotification(‘Invalid Credit Card Number.’, ‘ERROR’);
  • Xrm.Page.ui.setFormNotification(‘Invalid CVV Code.’, ‘WARNING’);

Microsoft CRM Pop-Up Message 5

There is an extra line of code to clear the message from the form, simply use the following method:

  • Xrm.Page.ui.clearFormNotification()

When there are many fields on one form, users may find it difficult to locate the fields that require correction (of course, additional methods can be developed to help locate such fields, for example, setFocus or setRequiredLevel).

In such a case, I would tend to use another alert, setNotification, that displays messages next to the fields. This way, fields can be visibly located and corrected.

  • Xrm.Page.getControl(“new_creditcardnumber”).setNotification(‘Invalid Credit Card Number.’);
  • Xrm.Page.getControl(“new_cvvcode”).setNotification(‘Invalid CVV Code.’);

Microsoft CRM Pop-Up Message 6

Deprecation of DynamicEntity and inclusion of early, late bound entity classes

In Microsoft Dynamics CRM 2011, you can choose from several programming scenarios to find the model that best suits your needs. The programming scenario in Microsoft Dynamics CRM 4.0 used the Web Services Description Language (WSDL) with early bound classes for each entity, and the DynamicEntity class for late-bound programming. You were also required to use late-bound programming for plug-in and custom workflow development. All of this has changed with the new programming models.

 

The main development scenario for Microsoft Dynamics CRM 2011 no longer uses the WSDL. Instead, you now reference two assemblies that allow you to connect to any Microsoft Dynamics CRM system for both early and late bound types. This scenario can be described as late binding or loosely typed. To use late bound types, use the Entity class. This class defines a collection of attributes that can be used to get and set the values of attributes. To use this model, the exact logical name must be known (and specified) as a string.

 

Alternatively, you can use early bound classes generated directly from the metadata, which include all customizations. The generated classes provide early binding and IntelliSense to aid you as you write custom code.

 

The DynamicEntity class has been replaced by the base class Entity. This means that all types are discoverable at both build time and runtime, making all strongly-typed entities now loosely-typed entities. You can use both programming scenarios in the same code as shown in the following example:

C#:

Account entity = new Account();
entity[“name”] = “My Account”; //loosely typed, late binding
entity.AccountNumber = “1234”; //strongly typed, early binding

The Microsoft Dynamics CRM SDK documentation includes samples that use both programming scenarios. The early bound samples use a file of strongly-typed classes that are generated with the code generation utility from a new, uncustomized installation of Microsoft Dynamics CRM. To run the samples, you must generate a file of strongly-typed classes from your installation. You can decide whether to create a proxy assembly from the generated code file or to include the file in your project directly.
@Information above is based on official Microsoft communication on the same.