Dynamics CRM Plugin Development: Pre-Operation vs Post-Operation Plugin Customization!

If you are a Dynamic CRM Developer, you need to know the importance of Dynamic CRM Plugin’s stages. We know there are four stages for Dynamic CRM Plugin Stage (3 we can custom, 1 is Dynamic CRM main operation):

1. Pre-Validation (outside the database transaction): avoid Update, Create, or Delete in this stage. This stage is good for the validation process (eg: throw an error if the position of the user is not high enough).
2. Pre-Operation (inside the database transaction): processes that run before the record being saved on the database. If got an error in this stage of after this stage, the data will be rollback.
3. Main-Operation: we can’t custom in here. Dynamics CRM main process to save the record in the database.
4. Post Operation (inside the database transaction): the process that can be put after the record being saved on the database. 

After knowing this behavior, I suggesting you only used Pre-Operation and Post-Operation only. The reason is Pre-Operation and Post-Operation are the only stages that support roll-back. While Pre-Validation is not transactionable.

Difference Between Pre vs Post

I saw a lot of Developers misunderstand about Pre-Operation and Post-Operation stage. In my company where I work, a lot of the code is assigned in the Post-Operation stage which causes the system to waste resources (unnecessary processes). For example, we have a custom on Order Entity in Post-Operation (assume we only have Post-Operation Stage only on Order’s Plugin Step):

For example, we have a custom on Order Entity in Post-Operation (assume we only have Post-Operation stage only on Order’s Plugin Step):

// Total Calculation
var totalAmount = GetTotalOrderFromDetail(orderId);
var order = new Entity("order") { Id = orderId };
order["totalamount"] = new Money(totalAmount);
_service.Update(order);

// Update IsPaid
var balance = GetBalance(orderId);
if(totalAmount == balance)
{    
    var update = new Entity("order") { Id = orderId };    
    update["new_ispaid"] = true;    
    _service.Update(update);
}

That code will trigger two times saving cycles into CRM which is not good:

Not efficient plugin process, 3 cycles spent

If you change it into stage Pre-Operation the code will look like this:

var entity = (Entity)context.InputParameters["Target"];
// Total Calculation
var totalAmount = GetTotalOrderFromDetail(orderId);
var order = new Entity("order") { Id = orderId };
entity["totalamount"] = new Money(totalAmount);

// Update IsPaid
var balance = GetBalance(orderId);
if(totalAmount == balance)
{    
    var update = new Entity("order") { Id = orderId };    
    entity["new_ispaid"] = true;
}

These changes will make CRM only process one time saving only (rely on Main-Operation to do saving). If you want to see the diagram will be:

Best solution you can have, process + save one cycle only

Problem

If you are creating a new plugin, it will be easier if you have this mindset. But if you are adding a feature to an existing plugin project, it will be harder to move from Post-Operation to Pre-Operation because we need to check a lot of things (refactoring is never an easy task). That’s why in this example, you can also consider these changes:

// Total Calculation
var totalAmount = GetTotalOrderFromDetail(orderId);
var order = new Entity("order") { Id = orderId };
order["totalamount"] = new Money(totalAmount);

// Update IsPaid
var balance = GetBalance(orderId);
if(totalAmount == balance)
{    
    order["new_ispaid"] = true;
}

//Saving only 1 time
_service.Update(update);

With these changes, of course, you will spend another extra process (one process extra, but it is better than the original):

Refactor result, much better with only 2 cycles

Summary

As a developer, we must know how to shoot our guns. Especially in Plugin Development, we must really understand this basic knowledge to utilize the resource of the System wisely. Performance matters.