When the standard low-code options cannot handle your business logic in an expected manner, as a developer, you can use custom event handlers in Microsoft Dataverse. The Event Framework provides the capability to register custom code to be run in response to specific events.
The custom code options available are Plugins, Azure integrations, virtual table data providers, and Webhooks, etc… When configured correctly using the plugin registration tool, these custom code extensions will respond to events that are provided by the event framework.
When an event occurs a message is sent to the organization Web service to process the event. The message contains information about the event, such as details of the table where the event occurred, dataverse organization details, details of the user who triggered the event, etc… There is a specific message for each event such as create, update, retrieve, retrieve multiple, associate, disassociate, delete, etc… Each message is processed in a series of 4 stages called the event execution pipeline and your custom code extension can be registered at any of these stages based on your business need. See the below table for the details about each stage.
| Stage Name | Description |
|---|---|
| PreValidation | This stage will occur before the main system operation. This provides an opportunity to include logic to cancel the operation before the database transaction. This stage occurs before any security checks are performed to verify that the calling or logged-on user has the correct permission to perform the intended operation. |
| PreOperation | Occurs before the main system operation and within the database transaction. If you want to change any values for an entity included in the message, you should do it here. Avoid canceling an operation here. Canceling will trigger a rollback of the transaction and have a significant performance impact. |
| MainOperation | For internal use only except for Custom API and Custom virtual table data providers. More information: Create and use Custom APIs Custom Virtual table data providers |
| PostOperation | Occurs after the main system operation and within the database transaction. Use this stage to modify any properties of the message before it is returned to the caller. Avoid applying changes to an entity included in the message because this will trigger a new Update event. Within the PostOperation stage, you can register steps to use the asynchronous execution mode. These steps will run outside of the database transaction using the asynchronous service. More information Asynchronous service. |
Hope this helps.
nijos.dev 