Pre-Validation vs Pre-Operation Stages in Dynamics 365 Plugins Complete Understanding

 

Pre-Validation vs Pre-Operation Stages in Dynamics 365 Plugins

When writing plugins in Dynamics 365, choosing the right execution stage is critical. Two commonly used stages are Pre-Validation and Pre-Operation. Although both execute before the main operation is committed to the database, their behavior is different.

---

⚡ Pre-Validation Stage

• Execution Context: Runs outside the database transaction.

• Rollback: Since it’s outside the transaction, any runtime error will not rollback the entire operation.

• Use Case: Ideal for implementing business logic that checks conditions before the database transaction starts. You can cancel the operation if needed.

• Security: Runs before security checks, so user permissions aren’t validated yet.

• Typical Usage:

  • Perform validations (e.g., duplicate detection).

  • Restrict operations before security checks.

• Example: Checking if a duplicate record exists in the system before allowing creation.

---

⚡ Pre-Operation Stage

• Execution Context: Runs inside the database transaction.

• Rollback: Any runtime error here will rollback the entire transaction, including other plugin steps.

• Use Case: Best when you need to modify target entity attributes or perform calculations within the transaction.

• Security: Executes after security checks, meaning the user must already have the right permissions.

• Typical Usage:

  • Update values in the entity being processed.

  • Perform operations that must be consistent with the transaction.

• Example: Debiting an amount from one record and crediting it to another within the same transaction.

---

📝 Key Differences at a Glance

Aspect	Pre-Validation	Pre-Operation
Transaction Scope	Outside transaction	Inside transaction
Rollback	❌ No rollback on failure	✅ Full rollback on failure
Security Checks	Before security check	After security check
When to Use	Validation, restricting operation	Modifying values, transactional logic
Example	Duplicate check	Debit/Credit logic

---

✅ Rule of Thumb:

• Use Pre-Validation for early validation & business rules.

• Use Pre-Operation for modifying data safely within the transaction.

Pre-Validation can restrict record creation or update.

Here’s why:

• Even though Pre-Validation runs outside the DB transaction, if you throw an exception in Pre-Validation, Dynamics will stop the pipeline right there and no DB transaction will even start.

• That means the record will not get created.

So:

• Yes, Pre-Validation can be used for duplicate checks and can prevent record creation.

• No, it doesn’t rely on rollback — because the transaction hasn’t started yet. Instead, the exception simply cancels the request before DB interaction.

---

🔹 Example

• You write a Pre-Validation plugin on Create Account.

• The plugin queries existing accounts for duplicate names.

• If a duplicate is found → you throw new InvalidPluginExecutionException("Duplicate record found").

• Result: The create operation is stopped

When Microsoft docs say Pre-Validation has no rollback, it means:

• At Pre-Validation stage, the database transaction hasn’t started yet.

• So if your plugin fails (throws exception), there is nothing to rollback, because no DB write has happened.

• The request is simply aborted before any database changes occur.

---

Compare with Pre-Operation (inside DB transaction)

• In Pre-Operation, the DB transaction has already started.

• If your plugin does multiple things (e.g., updates Account A, then Contact B), and then fails on Contact B → all changes (Account A and Contact B) will be rolled back automatically, since they are inside the same transaction.

---

✅ So meaning of “no rollback” =
Pre-Validation can still stop execution by throwing an error, but it doesn’t rollback anything, because the DB hasn’t yet touched data.