Configuration for CRM Plugins

CRM plugins are always great feature where we can automate many functionality which we cannot automate from user interface. But almost everyone of us might a faced a scenario where we may have to configure some data for the plugin to work. There are multiple solutions for such a situation like, create a custom entity where we can configure the data needed. But that can be costly if the configuration is required only for one plugin. In such a case, plugin itself has a feature for the same.

May be you have already noticed this feature while registering the plugin on the right hand side of the window where we create a step for the plugin. We have two types of configurations, secure and unsecure which differs only on how they are stored. The configurations can be of any format (like xml) but of type string. 

Now, let us discuss how to retrieve the same in our plugin code and use it. When we create a plugin include, a constructor for the plugin class, which takes two parameters of type string as follows,

public class SamplePlugin:IPlugin

{

    public SamplePlugin(string unsecureConfig,string secureConfig)

    {

       /* Now we have our configuration in the same format how it was added to          the plugin tool in the form of two parameters. The same can be extracted          as required for our implementation and use the same across the plugin. */

    }

}

A detailed way of implementation can be found here which is using an xml format to save configuration.

If different options with the advantages and disadvantages are to be discussed the information can be found here.

Configuring Business rules in CRM 2013

Business Rules let the system customizer apply conditional logic to a form. For using this feature, it not required to need any programming skills. This also helps to display error messages to the user that remind the users of the defined rules for a particular process. Such error messages prevent the user from saving a record until the issue is resolved.

When we create a business rule, we can apply the scope of the rule, it can be either to all forms, or just one form. If we want to apply a business rule to several forms and not all forms, we must create a copy of the rule for each form. Business rules will be enforced when the respective form is in use, irrespective of the platform, whether it is a browser, tablet or CRM for mobile applications.

Business rules are configured to apply client side logic to data in CRM 2013. This is instead of using processes or custom code that runs on the server, such as workflows or plugins. Business rules apply to data that a user enters or modifies in a form. A business rule must be activated before the logic in the rule takes effect.

Each active business rule that is associated with a specific form is evaluated when that form is loaded, or when the value changes in a field that is included in a condition that is defined in the rule. Business rules are not run again when a record is saved.

If a business rule includes a condition or an action that has a reference to a field that is not displayed on the form, the rule will not run, although an error is not created. It’s better to set non-event dependencies on a form to prevent other system customizers from removing a field without first removing the dependency.

The CRM for tablets client will only display the first 75 fields on a form. Therefore, any additional fields will not be displayed. We recommend that its made sure that all fields that are involved in the business logic that we have defined in Business rules are included in the first 75 fields on a form to avoid variable or unexpected behavior.

When we create a business rule at first its status would be draft and in this state it will not affect any other users. For testing, click the preview button on the ribbon to preview a version of the form. Activated rules and draft business rules are applied to the preview of the form. To apply the logic that is defined to the system, we must save the business rule before activating the same. While the rule is in active status we cannot delete or modify a business rule. For that first we have to deactivate the rule and then make the changes.

We must save the business rule at least once before we activate the rule. When we edit a rule that is already saved, only click save on the command bar if we change the name, conditions and actions would be saved individually.

For creating a similar rule like that of an existing rule, we can open the existing rule and then click on the save as button in the command bar. A new copy of the rule will be created, and we can make the required changes to the copy and then save the same.

If we make any changes to a field in the form using business rules, it will not reset the value automatically even if the condition is reverse now. For that we have to create another rule.

Adding a proper description to the rule is always recommended, which describes for what the rule is created and how it works or interacts with other rules.

Set the scope of a business rule

We can set the scope for the rule to all forms or select any one of the main or mobile forms. If we set the scope to any one form, we must create copies of the rule if we want to apply the rules to other forms, or we can change the scope to all forms if that is appropriate. In this case the rule will be applied to all forms of type Main or Quick Create. We cannot select the scope for a rule to apply only to the quick create form.

Conditions

Conditions define the fields that will cause the rule to be triggered, and the conditions to evaluate to determine whether the actions that are configured in the rule should be performed. We can add multiple conditions based on the same fields or different fields. All conditions must evaluate to “true” for the actions to be applied-this is a logical AND. We cannot do this for an OR.

When creating condition we can do this using the popular operators (=,>,<, or contains data). This depends on the data type of the selected field. Once the field and the operator is selected we have to select the condition type. There we have three options,

• ·         Field: To compare the value of the selected form field to another field. This can be done only for those fields which are in the form and of same data type.
• ·         Value: To compare the value with the value what we enter.
• ·         Formula: This option is available only for those fields which are numerical or date data types. This type can be used to compare the result of a simple calculation that can use either a value from another form field or value that we enter.

Actions

In a business rule, we can add actions from one of the following options,

·         Show error message: To set an error message on a field if the data in the field is not valid. The text we specify for the message will be displayed with an error icon near the field. The record cannot be saved while this message is displayed. If a user clicks the save icon, the focus will move to the first field that is on the form that has an error. If we change a field so that the rule is triggered and reevaluated, and the condition is no longer true, the error will be dismissed.

• ·         Set field value: Field value can be set in three different ways as did for conditions. If we use an action in the business rule to set the value of a field, the OnChange event handlers for that field will not run. So the JavaScripts configured for the onchange event will not be triggered.
• ·         Set business required: Change the requirement level for the field. The options are Not Business Required and Business Required. There is no option to set this to business recommended.
• ·         Set visibility: To change whether the field is displayed in the form. The options are show field and hide field. We cannot use this on sections or tabs.
• ·         Lock or unlock field: To change whether the field is enabled in the form. The options are lock and unlock. Once the field is locked users cannot edit that field.

For the last three options we have to set the reverse rule to set the property back if the opposite condition is true.

CRM - Handling Plugin Messages

In CRM when creating we will be handling multiple messages. I am trying to put different approaches we have to take based on messages in a single place. 

• Update

if (context.InputParameters.Contains("Target") && context.InputParameters["Target"] is Entity)
Entity entity = (Entity)context.InputParameters["Target"];

• Associate/Disassociate

if (context.InputParameters.Contains("Target") && context.InputParameters["Target"] is EntityReference)
EntityReference entityReference = (EntityReference)context.InputParameters["Target"];
if (context.InputParameters.Contains("Relationship"))
{
string relationshipName = context.InputParameters["Relationship"].ToString();
if (relationshipName == "relationshipnametocheck")
{}}}

   Reference.                     

• SetState/SetStateDynamicEntity

if (context.InputParameters.Contains("EntityMoniker") && context.InputParameters["EntityMoniker"] is EntityReference)
EntityReference entityReference = (EntityReference)context.InputParameters["EntityMoniker"];

If we have to trigger a plugin when a record status changes, its advisable to register the same for both tthe SetState and SetStateDynamicEntity. The reason why both the messages are required is both messages perform the same action in CRM and as there is not thumb rule for which action which message is fired, its better to register the plugin for both messages so that our plugin works properly. Reference.

CRM - Creating an email using REST endpoints

As a CRM developer everyone of us will undergo a scenario where now or tomorrow we may have to create an email record using REST endpoint. Its pretty easy that we can use any one of the REST approach and do that. But the challenge here is that REST endpoint does not support the party list. Because of this we cannot assign them to the email record which we create.

Solution for this is to create an activity (email) first and then create the a party list entity and link that to the created activity. To see how to do that we can refer to this simple but effective blog from "MS CRM Shop". 

Thanks team for this nice blog. 

Hope this helps !!!

CRM 2013 - Include Middle Name in contact's flyout control

By default, the contact's full name is populated as fly out control in CRM 2013. This will get reflected once the user enters the data and clicks on "Done" button.

The fly out control for the contact is based on the system settings. So if we need to make any changes to the fly out anchor the only way to do this right now is to change the system settings accordingly.

For example, by default the full name is set to have only first name and last name. If we need to have the middle name in the fly out control, include the middle name also in the contact name format under system settings.

For a detailed blog on this same subject please find it here.

Thanks Frank for such a nice blog. 

CRM 2013 - Composite Fields an overview

While trying to understand more on the composite control was able to see a blog in Community forums regarding the same. 

Thanks to the author for such a nice blog. 

Please read the same here.

Hope this help!!!

CRM 2013 - Refresh and Save functions

In CRM 2013, we have got two different functions one for saving the form and refreshing the form. Advantage of these two are that they are asynchronous in nature which can do the other activities based on the result of this refresh or save. So for example if we need to call function1 if the refresh/save was successful and function2 otherwise its pretty easy now.

We will look at refresh first,

Xrm.Page.data.refresh(save).then(

                function () {

                    //Do something if the refresh is successful

                },

                function () {

                    //Do something if the refresh is unsuccessful

                }

                );

In the above example save is a boolean value which should be used to mention whether we need to save the form after it is refreshed. If true then the form will be saved and if not then the form will not be saved.

Next we will look at the save function.

Xrm.Page.data.save().then(

                function () {

                    //Do something if the save operation is successful.

                },

                function () {

                    //Do something if the save operation is unsuccessful.

                }

                );

In both the above cases the success call back will not have any arguments. It will simply be called if the operation succeeds. At the same time error call back will be having an object with properties:

errorCode: The error code.

message: A localized error message.

One more thing to be noted for these functions are that these two are available only for updated entities.

Hope this helps!!!