Choose the right Dataverse extension for transaction risk
Diesen Beitrag auf Deutsch lesen
Match plug-ins, Custom APIs, webhooks and Service Bus to transaction, latency, security and ALM requirements.
TL;DR
Use synchronous plug-ins for validation or data changes that must succeed with a Dataverse save. Use Custom APIs for typed business operations with privilege checks. Use asynchronous Service Bus endpoints for decoupled volume, and webhooks for lightweight HTTPS notifications, while designing receivers for retries, payload limits and idempotency.
Original by Zsolt Zombik, on AIDevMe. Read the original
This is our own summary, not a republication or full translation.
Governance takeaway
- Makers: Use Custom APIs for named business operations instead of exposing arbitrary Dataverse writes to callers or agents.
- Admins/CoE: Add plug-in assemblies and steps to solutions, because secure configuration is not exported with a solution.
- Security/Compliance: Set a Custom API Execute Privilege Name and use server-side validation to restrict and govern who can run sensitive operations.
- Admins/CoE: Monitor Dataverse plug-in execution time, failures and activity in Power Platform admin center analytics.
Frequently asked questions
When should a Dataverse plug-in run in PreValidation instead of PreOperation?
Use PreValidation to reject invalid input before the initial database transaction starts. Use PreOperation when the plug-in must change target values before saving.
How can a Dataverse Custom API restrict who can call an agent operation?
Set an existing Execute Privilege Name on the Custom API. Its plug-in can then apply server-side validation within the named, typed operation.
What happens when a Dataverse webhook payload exceeds 256 KB?
Dataverse adds the x-ms-dynamics-msg-size-exceeded header and removes context, input parameters, and image collections. Webhook receivers must account for the reduced payload.