CRM interview Questions

 🛠️ Execution Order: JavaScript vs Business Rules

1. JavaScript

   • Runs immediately on the client-side when triggered by form events (e.g., OnLoad, OnChange, OnSave).
   • It executes before Business Rules if they are tied to the same event.

2. Business Rules

   • These are client-side validations that run after the JavaScript code when triggered by form changes.
   • They are evaluated after JavaScript completes, but they also run on the server-side when saving records if they are configured to do so.

📊 Why Does JavaScript Run First?

• JavaScript has direct access to the DOM and executes immediately when form events occur.
• Business Rules depend on form data being updated, and they act more like a validation layer after JavaScript changes have been applied.
• JavaScript can modify fields before Business Rules evaluate their conditions, which allows JavaScript to control or influence Business Rule outcomes.

🚀 Example Scenario:

1. A field (Field A) has a JavaScript OnChange event and a Business Rule applied.
2. When Field A changes:
   • JavaScript executes first and can set or modify Field B.
   • After JavaScript finishes, the Business Rule evaluates its conditions (including any changes JavaScript made).

✅ Key Takeaways:

• Client-Side: JavaScript runs before Business Rules.
• Server-Side (e.g., on Save): Business Rules execute independently from client-side JavaScript.
• JavaScript is more flexible and powerful but requires coding knowledge.
• Business Rules are easier to configure but offer less granular control.

If you're designing a solution, it’s best to use JavaScript for complex logic and Business Rules for simple validations or field updates.

---

🚀 Steps to Prevent Cascade Delete in a Plugin

1. Create a Pre-Operation Plugin on the Contact Entity Delete Event

• Register the plugin on the Pre-Operation (PreValidation) stage of the Delete message for the Contact entity.

2. Write the Plugin Code

Below is an example of the plugin code:

using System;
using Microsoft.Xrm.Sdk;

public class PreventCascadeDeletePlugin : IPlugin
{
    public void Execute(IServiceProvider serviceProvider)
    {
        // Obtain the execution context
        IPluginExecutionContext context = (IPluginExecutionContext)serviceProvider.GetService(typeof(IPluginExecutionContext));

        // Check if the plugin is triggered by a Delete event
        if (context.MessageName.ToLower() != "delete")
            return;

        // Verify that the target entity is 'contact'
        if (context.PrimaryEntityName.ToLower() != "contact")
            return;

        try
        {
            // Get the service factory and organization service
            IOrganizationServiceFactory serviceFactory = (IOrganizationServiceFactory)serviceProvider.GetService(typeof(IOrganizationServiceFactory));
            IOrganizationService service = serviceFactory.CreateOrganizationService(context.UserId);

            // Prevent cascading delete
            // Example: Retrieve related custom entity records and remove their association or skip their deletion
            QueryExpression query = new QueryExpression("custom_entity")
            {
                ColumnSet = new ColumnSet("custom_entityid"),
                Criteria = {
                    Conditions = {
                        new ConditionExpression("contactid", ConditionOperator.Equal, context.PrimaryEntityId)
                    }
                }
            };

            var relatedRecords = service.RetrieveMultiple(query);

            foreach (var record in relatedRecords.Entities)
            {
                // Optional: Nullify the lookup to break the relationship
                Entity updateEntity = new Entity("custom_entity");
                updateEntity.Id = record.Id;
                updateEntity["contactid"] = null; // Remove the association

                service.Update(updateEntity);
            }
        }
        catch (Exception ex)
        {
            throw new InvalidPluginExecutionException($"Error in PreventCascadeDeletePlugin: {ex.Message}");
        }
    }
}

3. Register the Plugin in CRM

1. Use the Plugin Registration Tool.
2. Register the plugin on the Delete event of the Contact entity.
3. Set the Execution Stage to PreValidation.

🛡️ Alternative: Change Relationship Behavior

If you have access to the relationship settings in CRM, you can:

1. Go to Advanced Settings → Customizations → Customize the System.
2. Open the relationship between Contact and Custom Entity.
3. Change the Delete Behavior from Cascade All to Remove Link or Restrict Delete.

👉 Note: Adjusting the relationship behavior is generally more efficient than managing this in a plugin if possible.

---

🔑 Key Differences Between Plugin and Workflow in CRM Online

Aspect	Plugin	Workflow
Purpose	Used for complex, real-time business logic requiring high customization.	Used for process automation with standard rules and conditions.
Execution Mode	Synchronous (Real-time) or Asynchronous (Background).	Primarily Asynchronous (Background). Real-time workflows are also available but less performant.
Trigger Points	Triggered on events (e.g., Create, Update, Delete, Associate, Disassociate).	Triggered on events (e.g., Create, Update, Delete) or can run manually.
Customization	Requires .NET/C# development skills. Offers more flexibility.	Configurable via the CRM UI without coding.
Performance	Better performance for complex and high-volume operations.	Slower for complex operations; better suited for straightforward tasks.
Error Handling	Advanced error handling and logging can be implemented.	Limited error handling and logging options.
User Interface	No UI; entirely backend logic.	Can be managed and updated via the CRM UI.
Reusability	Can be reused across multiple entities via registration.	Limited reusability, mostly scoped to specific workflows.
Security	Runs under the security context of the calling user or SYSTEM user.	Runs under the security context of the workflow owner.
Deployment	Requires deployment via Plugin Registration Tool.	Easily exportable/importable via Solutions.

🚀 When to Use Plugins vs Workflows?

Use Plugins When:	Use Workflows When:
Real-time or complex calculations and validations are needed.	The process involves simple rules and actions.
The logic needs to interact with external systems or APIs.	The logic can be achieved using available workflow actions.
High performance and scalability are essential.	Process execution can happen asynchronously.
Advanced error handling and logging are required.	The task is straightforward and does not need custom code.
Complex business rules are involved.	Business users need the flexibility to modify the rules via the UI.

🛠️ Example Scenarios

• Plugin Example: Automatically calculate a discount on an invoice based on custom logic when an order is created.
• Workflow Example: Send an email notification when an opportunity is closed.

In summary:

• Plugins are more powerful, flexible, and require coding.
• Workflows are easier to configure but are less flexible and more limited in scope.

If you're deciding which one to use, the complexity and performance requirements of the task should guide your choice.

---

In Microsoft Dynamics 365 CRM Online, a pre-validation plugin is a type of plugin that executes before the main operation starts and even before the transaction begins. It is part of the Event Execution Pipeline and is typically used for validating data, performing security checks, or ensuring business rules are met before proceeding with the actual operation.

🔑 Key Characteristics of Pre-Validation Plugins

1. Execution Stage:

   • Pre-validation plugins execute in Stage 10 of the plugin execution pipeline.
   • They run before the core platform operation (like creating, updating, or deleting a record).

2. When They Execute:

   • Before the transaction starts.
   • Before any data changes are committed to the database.

3. Use Cases:

   • Data Validation: Ensure the input data meets specific criteria.
   • Business Rule Enforcement: Prevent certain operations if specific conditions are not met.
   • Security Checks: Verify that the user has the correct permissions to perform the operation.
   • Prevent Invalid Operations: Stop execution if a condition fails, preventing unnecessary operations.

4. Rollback Behavior:

   • Since this stage occurs before the transaction starts, it does not require a rollback if an exception occurs.

5. Performance Impact:

   • Pre-validation plugins are generally faster because they avoid interacting with the database.

⚙️ When to Use Pre-Validation Plugins?

• Validate if required fields are populated before saving a record.
• Ensure no duplicate records exist before creation.
• Check business rules that should prevent the transaction entirely.
• Prevent specific updates or deletions based on conditions.

📚 Example Scenario:

Imagine you're developing a registration validation plugin in MS CRM:

• Requirement: Prevent duplicate registrations for the same person and same date of birth.
• Solution: Write a Pre-Validation Plugin on the Create event of the Registration entity.
• Outcome: If a duplicate is detected, the plugin will throw an exception, and the record creation will stop.

public void Execute(IServiceProvider serviceProvider)
{
    var context = (IPluginExecutionContext)serviceProvider.GetService(typeof(IPluginExecutionContext));
    if (context.MessageName != "Create") return;

    var target = (Entity)context.InputParameters["Target"];
    var personId = target.GetAttributeValue<EntityReference>("personid")?.Id;
    var dob = target.GetAttributeValue<DateTime>("dateofbirth");

    // Check for duplicate records logic
    if (DuplicateRecordExists(personId , dob))
    {
        throw new InvalidPluginExecutionException("Duplicate registration detected for the same person and DOB.");
    }
}

✅ Key Takeaways:

• Stage: Pre-Validation (Stage 10)
• Purpose: Validate data, enforce rules, and prevent unwanted operations before transactions start.
• Best Practice: Use Pre-Validation for critical checks that must happen before data hits the database.

Let me know if you want help with a specific validation scenario or more details on writing a pre-validation plugin! 🚀

---

How to Avoid Infinite Loops in MSCRM Plugin Code

Infinite loops in Microsoft Dynamics 365 (MSCRM) plugins typically occur when a plugin triggers an event that causes itself to re-execute indefinitely. For example, a plugin on an Update event makes another Update to the same record, triggering itself repeatedly. Below are strategies to prevent and manage such scenarios.

⚠️ Common Causes of Infinite Loops in Plugins

1. Recursive Updates: The plugin updates a field on the same entity record without checking if the change is necessary.
2. Incorrect Trigger Logic: Plugins are triggered by unintended events.
3. No Exit Conditions: The plugin lacks a mechanism to prevent re-entry or re-triggering.
4. Multiple Plugins Interfering: Plugins inadvertently trigger each other in a loop

🔄 Quick Checklist for Infinite Loop Prevention

✅ Check context.Depth to prevent recursion.
✅ Use targeted field updates.
✅ Implement a plugin-specific flag field.
✅ Validate changes with preImage and postImage.
✅ Ensure correct registration (Message, Stage, Filtering Attributes).
✅ Log trace details for monitoring.

---

🛠️ The Purpose of IsValidForUpdate Field in MS CRM Plugins

The IsValidForUpdate field is a system field in Microsoft Dynamics 365 (MSCRM), used primarily to control the updateability of certain fields or records under specific circumstances, especially during the execution of plugins or workflow processes.

While the field itself isn't directly visible in most user interfaces, it plays a role in managing the validity of updates to certain fields based on various business rules.

IsValidForUpdate is used in plugins to control the updateability of records or fields during asynchronous and synchronous operations.

It allows you to validate or block updates based on custom business logic.

It is commonly used in Pre-Operation plugins to ensure that only valid changes are allowed and to prevent invalid updates.

---

Execution Order:

1. JavaScript (Client-Side) → Executes first.
2. Synchronous Plugin → Executes before the synchronous workflow (Real-Time).
3. Synchronous Workflow (Real-Time) → Executes after the synchronous plugin.
4. Asynchronous Plugin → Executes after the synchronous processes are completed but queued in the background.
5. Asynchronous Workflow → Executes after the asynchronous plugin, but both are handled asynchronously and independent of each other.

---

⚠️ Things to Consider:

• JavaScript is for client-side logic and will always execute before the data is sent to the server.
• Synchronous Plugins have higher priority in the pipeline compared to Synchronous Workflows.
• Both Asynchronous Plugins and Asynchronous Workflows run in the background and are dependent on queue processing, so their order may vary.

---

🏛️ Property to Check Whether a Plugin Executes Within a Database Transaction in MS CRM

In Microsoft Dynamics 365 (MSCRM), the property that controls whether a plugin executes within the same database transaction or not is the IsolationLevel property of the IPluginExecutionContext interface.

🔍 The IsolationLevel Property

• The IsolationLevel determines whether the plugin will execute within the current database transaction.
• This property can have the following values:
  • None: The plugin executes outside of a transaction. This means the plugin runs independently and does not affect the current transaction.
  • Serializable: The plugin executes within a transaction, meaning it is part of the same database transaction that is being processed for the operation (e.g., Create, Update, Delete). If the operation fails, the plugin’s changes will also be rolled back.
  • ReadCommitted: Executes within a transaction, ensuring that the plugin works with committed data but may allow the plugin to see data that is in the process of being committed.

Key Points:

1. Transaction Boundaries: If the plugin is executed within the same transaction (Serializable), it will be part of the unit of work (i.e., changes to the database will be committed or rolled back together).
2. Transaction-independent Execution (None): If the plugin is executed outside the transaction, it will be independent of the changes made to the database, and even if the main operation fails, the plugin logic will not be rolled back.
3. Impact on Rollback: If the IsolationLevel is set to Serializable and the operation fails, the plugin's changes are also rolled back as part of the transaction.

---

What Happens If a Synchronous Plugin Fails When an Asynchronous Plugin Is Also Registered on the Same Entity and Event?

In Microsoft Dynamics 365, when both a Synchronous Plugin (Sync) and an Asynchronous Plugin (Async) (or Async Workflow) are registered for the same entity and event, the behavior depends on whether the Synchronous Plugin fails or succeeds.

Scenario: Sync Plugin Fails, What Happens to the Async Plugin?

1. Synchronous Plugin Fails:

   • If the Synchronous Plugin fails (e.g., due to an exception or validation failure), the transaction will be rolled back. This means that the changes to the database (such as create, update, or delete operations) will be undone, and the user will receive an error indicating the failure.

2. Impact on Asynchronous Plugin:

• Even though the Synchronous Plugin fails and causes a rollback, the Asynchronous Plugin will still be triggered.
• This happens because the Asynchronous Plugin operates after the transaction is completed and is placed in the asynchronous queue for execution. The asynchronous plugins are not part of the same database transaction and thus are not rolled back as part of the failure in the synchronous part.

Key Points:

• The Synchronous Plugin failure does not affect the execution of the Asynchronous Plugin.
• If the Synchronous Plugin fails, the database transaction is rolled back, but the Async Plugin is still placed in the asynchronous processing queue and will be executed regardless of the outcome of the sync plugin.
• However, if the Async Plugin’s logic depends on changes made by the Sync Plugin, you may encounter issues where the Async Plugin doesn't have the expected data or conditions, potentially leading to failures in the Async Plugin’s execution as well.

📊 Execution Flow:

1. Sync Plugin Execution:

   • The sync plugin is executed first.
   • If the sync plugin fails, any changes to the database (create/update/delete) are rolled back.

2. Async Plugin Execution:

   • If the sync plugin fails but the operation was not aborted due to the failure (e.g., if it's a soft failure or there's no rollback for specific failure types), the async plugin will still be placed in the asynchronous queue.
   • The async plugin runs independently and will be executed after the synchronous operation (regardless of whether the synchronous operation was successful).