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):
- 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).
- 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.
- Main-Operation: we can’t custom in here. Dynamics CRM main process to save the record in the database.
- 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:

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:

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):

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.
One thought on “Dynamics CRM Plugin Development: Pre-Operation vs Post-Operation Plugin Customization!”