If the purpose of your plugin is to validate (what’s in a name) data in your record or normalizing it before save, chances are you want to use the Pre-Validation stage.
On a recent project, I saw people consistently doing these kinds of validations in the pre-operation.
What’s the big difference?
Well let’s have a look at the MSDN and the pipeline stages.
The important thing to note in each stage is if it’s executed within the database transaction or not.
If anything goes wrong in the transactional steps (20-40) the operation will rollback.
Since the pre-validation (stage 10) is outside of the transaction this makes it the perfect place to validate and normalize data, before starting a commit operation to the database.
Once you are in the pre-operation (stage 20) you can create records that relate to the current record, nicely wrapped in 1 transaction. (watch out for those child records and their plugin pipelines though, but we will elaborate on that one in another blogpost).
If all goes well in the Main Operation (stage 30) you can use the post-operation (stage 40) message to for example communicate changes to ESB or a web service. Remember that is anything goes wrong within this step the transaction will rollback, which makes communicating changes transaction-safe from the CRM side.