On-premise plug-in development

Artigo
12/13/2024

A plug-in is custom business logic (code) that you can integrate with Dynamics 365 Customer Engagement (on-premises) to modify or augment the standard behavior of the platform. Another way to think about plug-ins is that they are handlers for events fired by Dynamics 365 Customer Engagement (on-premises). You can subscribe, or register, a plug-in to a known set of events to have your code run when the event occurs.

For more information about plug-in run-time execution, see Event Framework.

Note

The documentation that follows describes additional options only available in on-premises environments. For general information about writing plug-ins that work for both on-premises and online deployments, read the Use plug-ins to extend business processes topic in the Dataverse documentation.

Best practices for on-premise plug-in development

This section includes best practices specific to on-premise plug-in development

Don't depend on references to variables passed into plug-ins

In an on-premises environment where a full trust plug-ins are executed within the same app domain, don't expect that a variable that refers to data included in the plug-in context will maintain a reference to the object.

When data is passed into the event pipeline, the data is serialized and de-serialized to create a new object instances. The object instances do not refer to the same memory address. Any changes to the object in the plug-in execution pipeline will not be reflected in an object instance that was passed into an operation in the pipeline.

For example, if you define a QueryExpression that is included in a RetrieveMultipleRequest, if there is any code within a plug-in that changes the QueryExpression, that change will not occur on the original QueryExpression instance variable that was passed with the RetrieveMultiple request. Within the pipeline, the QueryExpression object properties may be updated in the process of retrieving the data. For example, the QueryExpression.PageInfo property will be updated as a part of executing the query. You will not be able to detect these changes by examining the original QueryExpression variable that was used with the RetrieveMultipleRequest.