MS CRM Interview Questions

1. What is Isolation mode for Plug-Ins?

2. How to call external WCF Service in Plugin or in a custom Workflow in MS CRM?

3. How to Call After Save Event in MS CRM 365?

4. What is Difference between Owner Team and access Team in MS CRM?

5. Difference between Business Rules and Custom Javascript?

6. How to Handle infinite loop for Plugin?

7. What is Plugin Dept?

8. What are the Client Side Events in MS CRM?

9. What is Secured Vs. Unsecured Configuration of Plugin?

 10. How to fetch records from Entity having N:N relationship?

11. What are Entity Types and Entity Ownership in MS CRM?

12. What is String Map table in MS CRM?

13. What is Relationship Behaviour in MS CRM?

14. Explain Hierarchy Visualization in MS CRM?

 15. How Business Process Flow works in Microsoft Dynamics CRM?

16. How to choose Microsoft Dynamics CRM On-Line and On-Premise?

17. Where Plugin Assembly storage location?

18. How to know Organization database name?

19. What is Web Resource Utility?

20. What is CRM REST Builder?

21. What is IME mode option while creating new Attribute?

22. What are the important changes in MS CRM 365 (Version 9) for development point of view?

23. What is Multi Select Option Set in MS CRM?

24. How to change field color in MS CRM 365?

Call an external WCF service from a custom workflow or a plugin in MS CRM

Call an external WCF service from a custom workflow or a plugin in MS CRM

As we know very well custom workflow and plugins are the class libraries and obviously there is no configuration file associated with class libraries projects and that is the reason we have to follow below approach to call an external WCF service from the plugin or workflow.

First of all a proxy file needs to be generated using svcutil.exe. This command needs to execute from the command prompt. To generate the proxy file, navigate to the location of the svcutil.exe on the machine (C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.7.2 Tools) and execute the following:

C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.7.2 Tools>svcut

il.exe /language:cs /out:proxy.cs /config:app.config <SVC Service>

After executing the command a proxy.cs file is generated at the location of the svcutil.exe. This proxy.cs should be included in the workflow or plugin solution. 

Once the generated proxy.cs file added into the project, for the bindings of WCF service below code should be written where you wanted to call the service.

 

  BasicHttpBinding serviceBinding = new BasicHttpBinding();

  serviceBinding.Name = "<Binding Name>";

  serviceBinding.Security.Mode = BasicHttpSecurityMode.None;

  serviceBinding.Security.Transport.ClientCredentialType = HttpClientCredentialType.None;

  serviceBinding.Security.Transport.ProxyCredentialType = HttpProxyCredentialType.None;

  serviceBinding.Security.Message.ClientCredentialType = BasicHttpMessageCredentialType.UserName;

  EndpointAddress endPointAddress = new EndpointAddress("http:<ServiceURLPaTH>.svc");

  ServiceClient serclient = new ServiceClient(serviceBinding, endPointAddress);

Now you can use Serclient object to call the service methods.

Hope this will be helpful.

Assembly must be registered in isolation Error-

Recently my QA team has encountered the error – “Assembly must be registered in isolation” while importing the solution which contains the plug in assemblies, although everything was fine in development environment.

The reason behind the error is the user was not a Deployment Administrator, if the user is only a System Administrator in the organization, they will be forced to register plugins in the sandbox isolation mode.

Thank you.

Call After Save Event in MS CRM 365 Form

We have recently faced a problem while reloading the form after save MS CRM Entity form. Initial thought was like this is pretty simple functionality we have to achieve and will not take more time but unfortunately when we started implementing it we got stuck in iterative problems.

 We did tried using the below code which called onSave of the form-

onSave()

{

    Xrm.Page.data.entity.save();

    setTimeout(function () {

        Xrm.Utility.openEntityForm(Xrm.Page.data.entity.getEntityName(), Xrm.Page.data.entity.getId());

    }, 3000);

}

But unfortunately it did not worked, we even tried the same code on the success and failure callbacks of the Xrm.Page.data.entity.save() but there is no luck, most of the time it executed fail callback of the method.

After spending some time on the Google we found the below solution and it worked 100 percent-

First of all we have created a helper function to set or remove listener to internal CRM events:

function addAfterEventHandler(eventId, handler) {

    this.parent.Mscrm.TurboForm.Control

    .CommandService.get_instance()

    .addAfterCommandExecutionHandler(eventId, handler);

}

function removeAfterEventHandler(eventId, handler) {

    this.parent.Mscrm.TurboForm.Control

    .CommandService.get_instance()

    .removeAfterCommandExecutionHandler(eventId, handler);

}

After creating the helper function we have added the listener to the after save event-

addAfterEventHandler(this.parent.Mscrm.InlineCommands.Save, function () {

    Xrm.Utility.openEntityForm(Xrm.Page.data.entity.getEntityName(), Xrm.Page.data.entity.getId());

});

We created the web resource of the above code and loaded the same on the form of entity where we required, that's all whenever you will save the changes for the particular form it will reload the page.

MS CRM Owner Teams vs Access Teams

In Microsoft Dynamics CRM 2011, the Team concept that was used is now known as Owner Teams in Microsoft Dynamics CRM 2013. The new version of CRM also introduces a new team type called Access Teams. Two fundamental differences between an Owner Team and an Access Team involve ownership and sharing. As the name implies, a member of an Owner Team inherits permissions to the records because the team owns the record. Access Teams are different in that permissions are granted to the records via sharing.

Now that there are two team types, when should you use one over the other? Since owner teams are a known concept with the two previous releases of CRM, only the best practice of when to use them will be defined in comparison to access teams.

Owner Teams

• Best where teams access high volumes of data, via ownership or business unit access
• When a security role is required to access records scoped by a business need
• Teams used as service scheduling resource must be owner teams

Access Teams

• Rapidly changing team memberships
• Allows for >1,000 team memberships per user
• Individual record based access
• Owner of the record allowed to define access to other users
• Can accommodate varying levels of group access types to records

MS Dynamics CRM: Business Rules vs JavaScript

Business Rules were introduced as an out-of-the-box MS Dynamics CRM 2013 feature and provide CRM administrators with the ability to implement custom form logic via a simple to use designer UI. The designer UI enables non-technical individuals to implement interface driven business logic without the need for JavaScript. The end result is delivered faster and with less expense than custom script development.

Business Rules monitor the behaviour of fields on a form and define one or more actions to be performed when the conditions are met. The following are conditions that can be evaluated:

• Check a fields value against a static value
• Check a fields value against the value of another field on the same form
• String multiple conditions together separated by AND in one clause

The following defines the actions that can be performed when certain conditions are met on the form:

• Show error message
• Set field value
• Set field required or not
• Set field visibility
• Lock or unlock a field

Business rules are created for an entity:

 

Improvements have been made to Business Rules in MS Dynamics CRM 2015 and include:

• Rules to set default values for a field
• Support for if/else in their condition statements
• Support for and/or conditional rules
• Server side logic execution

Even with the improvements Business Rules cannot always satisfy complex business logic and administrators need to be able to identify when custom JavaScript development may be required. The following are some of the limitations of Business Rules:

• • Business rules run only when the form loads and when field values change. They do not run when a record is saved, unless the scope for the rule is set at an entity level.
  • Business rules work only with fields. If you need to interact with other visible elements, such as tabs and sections, within the form you need use form scripts.
  • When you set a field value by using a business rule, any OnChange event handlers for that field will not run. This is to reduce the potential for a circular reference, which could lead to an infinite loop.
  • If a business rule references a field that is not present on a form, the rule will simply not run. There will be no error message.
  • Whole Number fields that use the formats for TimeZone, Duration, or Language will not appear in the rule editor for the conditions or actions, so they cannot be used with business rules.
  • You can’t add more than ten if-else conditions in a business rule.
  • For Microsoft Dynamics 365 for tablets, the definition of the business rules are downloaded and cached when Dynamics 365 for tablets opens. Changes made to business rules are not applied until Dynamics 365 for tablets is closed and re-opened.
  • When you set the value of a lookup field, the text of the primary field value that is set in the form will always match the text that is visible in the rule definition. If the text representing the primary field value of the record you are setting in the lookup changes, the value set by your rule will continue to use the text portion of the primary field value defined by the rule. To fix this, update the rule definition to use the current primary name field value.
  • It is useful to understand that the value set for a lookup has three parts:
  • Name: The text of the primary field value you see in the form.
  • Id: The unique identifier for the record. This is the data that is saved. This is not visible in the form.
  • LogicalName: The name of the entity, such as contact, account, or opportunity.
  • The rule will set all three parts of this value. The Id value for a specific record never changes, but the Name value might change.
  For example, if you define a rule to set a lookup to a contact that has the Full Name of ‘Old Name’, this text is the Name you will see in the lookup when it is set by your business rule even if someone later changes the Full Name of the contact to ‘New Name’. The lookup Id value will be correctly set to the expected record, but the Name (which is not saved) will reflect the rule definition value rather than the current Full Name value of the record it references.
  At the end of the day even with its limitation Business Rules are a powerful feature which enables the quick and cost effective implementation of custom form logic. And with future releases of MS Dynamics CRM we can only expect further improvements.

What is plugin dept in MS CRM Or stopping infinite loop in Plugin

Depth is often used to stop infinite loops where a plugin updates a value which triggers the plugin to run again.

A common cause of this is bad programming practice where a plugin retrieves the target entity and at the end of the plugin updates the entity.

e.g. 

1. A post plugin triggered on update of account name.

2. Plugin retrieves target entity

3. Plugin updates name field on target entity field to name + unique number

4. Plugin does CrmService.Update (target entity);

Plugin has updated field value which triggers plugin again The way around this is to put code in a pre plugin. 

It’s possible to check the depth of the plugin-

IPluginExecutionContext context = (IPluginExecutionContext)serviceProvider.GetService(typeof(IPluginExecutionContext));

            if(context.Depth > 1)

                return;

Every time a running plug-in or Workflow issues a message request to the Web services that triggers another plug-in or Workflow to execute, the Depth property of the execution context is increased. If the depth property increments to its maximum value within the configured time limit, the platform considers this behavior an infinite loop and further plug-in or Workflow execution is aborted.

The maximum depth (8) and time limit (one hour) are configurable by the Microsoft Dynamics 365 administrator using the PowerShell command Set-CrmSetting.

The setting is WorkflowSettings.MaxDepth. For more information, see, “Administer the deployment using Windows PowerShell” in the Deploying and administering Microsoft Dynamics CRM.