PreOperation vs PostOperation for Action Plugin Registration in Dynamics 365

When developing a plugin for a custom action in Dynamics 365, choosing the correct plugin registration stage is crucial. This article explains the differences between PreOperation and PostOperation, highlights a real failure case, and provides best practices for plugin registration.

PreOperation vs PostOperation for Action Plugin Registration

Registration Stage	When It Executes	Best Use Case	Limitations
PreOperation (Stage 20)	Before the main operation runs	Validate or modify input parameters before execution	Cannot modify or return output parameters
PostOperation (Stage 40)	After the main operation completes	Compute and return output parameters to workflows or other processes	None (best choice for returning data)

Key Rule: If the plugin modifies input parameters, use PreOperation. If the plugin sets output parameters, use PostOperation (required for workflows to receive output values).

Failure Case: Incorrect Plugin Registration Stage

Scenario

A custom action named AddBusinessDays was created to add a specified number of business days to a given date. A plugin was developed to handle the calculation and return the adjusted date via an output parameter (ResultDate). However, the plugin was initially registered in PreOperation.

Plugin Log Excerpt

Starting AddBusinessDays plugin execution.
Input - BaseDate: 3/4/2025 6:43:43 PM, BusinessDaysToAdd: 3
Intermediate resultDate: 3/5/2025 6:43:43 PM, daysAdded: 1
Intermediate resultDate: 3/6/2025 6:43:43 PM, daysAdded: 2
Intermediate resultDate: 3/7/2025 6:43:43 PM, daysAdded: 3
Final resultDate: 3/7/2025 6:43:43 PM
Finished AddBusinessDays plugin execution.

Issue: Unexpected Output in Workflow

Despite the plugin correctly computing the ResultDate, the workflow received "01/01/0001 12:00 AM" (DateTime.MinValue), indicating the action did not return the expected output.

Root Cause

The plugin was registered in PreOperation, which does not support returning output parameters. Since output parameters are only available in PostOperation, the workflow could not retrieve the computed ResultDate.

Resolution: Move Plugin to PostOperation

The issue was fixed by re-registering the plugin to run in PostOperation (Stage 40, Synchronous mode). After this change, the workflow correctly received the computed ResultDate.

Updated Registration:

• Message: AddBusinessDays
• Stage: PostOperation (40)
• Execution Mode: Synchronous

Now, the workflow correctly captures the computed date.

Best Practices for Plugin Registration in Actions

• Use PreOperation when:
  • Validating or modifying input parameters before the action executes.
  • Preventing unnecessary execution if conditions aren’t met.
• Use PostOperation when:
  • Setting output parameters that need to be passed to a workflow or another calling process.
  • Performing calculations based on the final state of the operation.
• Ensure the following when using PostOperation:
  • The output parameter name in the action definition matches the plugin’s OutputParameters key (case-sensitive).
  • The data type of the output parameter is correct (e.g., DateTime for dates).
  • The plugin step is published and registered correctly.

Conclusion

Understanding PreOperation vs PostOperation is essential for custom action plugin registration in Dynamics 365.

• If you need to validate input → Use PreOperation.
• If you need to return an output parameter → Use PostOperation.

In this failure case, the output parameter was not returned because the plugin was registered in the PreOperation stage. Switching to PostOperation resolved the issue, ensuring the action returned the expected result.

By following these best practices, you can avoid common plugin registration mistakes and ensure smooth execution in Dynamics 365 workflows.