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.
- The output parameter name in the action definition matches the plugin’s
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.
No comments:
Post a Comment