How Every Plugin Action Travels Through Request, Service, and the Pipeline
In Dataverse plugin development, a request is simply a message that tells Dataverse what action to perform. This could be a basic action like Create, Update, Delete, Retrieve, or a special action like Assign or SetState.
Understanding requests is important for developers and architects because they affect how the plugin runs, how transactions work, and how multiple record updates stay consistent.
Think of it this way:
- A request says what needs to happen
- A service (`IOrganizationService`) is the worker that does the job
Together, they are the core of how plugins work in Dataverse. They:
- Allow you to design plugins that work in a single transaction
- Make sure changes are consistent and traceable
- Work smoothly with the plugin pipeline to follow business logic
For architects:
- Service = the executor
- Request = the action
- Plugin pipeline = the traffic controller that manages transactions and triggers during plugin execution.
Service (`IOrganizationService`)
What it is:
- The gateway interface that a plugin (or any client) uses to interact with Dataverse.
Role in architecture:
- Acts as the executor of business operations such as Create, Update, Delete, Retrieve, and Execute (for special operations).
Key architectural concerns:
Who executes the service?
- Can run as current user or system user (elevated privileges).
- This affects security, auditing, and transaction scope.
When to use:
- Any time a plugin must interact with Dataverse beyond the triggering record.
Request (`OrganizationRequest`)
What it is:
- A message object that defines what specific operation should happen in Dataverse.
Role in architecture:
- Encapsulates business operations (Create, Update, Assign, SetState, ExecuteMultiple).
- Supports batch operations and specialized requests like `WinOpportunityRequest`.
Key architectural concerns:
- Requests define the payload that travels through the plugin pipeline.
- Can trigger recursive plugin executions if designed without proper depth checks.
- PreValidation (Stage 10) – Before transaction starts
- PreOperation (Stage 20) – Inside transaction, before database commit
- Main Operation (Stage 30) – Dataverse core applies changes
- PostOperation (Stage 40) – After commit (synchronous), or async
- Synchronous Plugins (Pre & Post Operation)
- All service.Execute(request) calls are part of one transaction.
- Execute after transaction commit.
- Service calls are isolated → no rollback of the original operation if they fail.
- Use synchronous for business-critical & atomic changes.
- Use async for heavy operations or external integrations to avoid blocking user actions.
- Minimize unnecessary Service calls – Reduces execution time and avoids plugin timeouts
- Leverage batch requests with ExecuteMultipleRequest for efficiency and atomicity
- Use proper security context:
- System user for back-end automation
- Calling user to maintain audit trail
- Separate atomic vs non-atomic operations:
- Atomic → Pre/Post synchronous
- Non-atomic → Async or external service
Published on:
Learn moreWe can help you with How Every Plugin Action Travels Through Request, Service, and the Pipeline
If you want help implementing, troubleshooting, or improving this product, contact us and we’ll point you in the right direction.
Related posts
Copilot Studio: Agent Integration Approaches — Tools, Knowledge, and Agents
In Copilot Studio, agent integration employs the same fundamental integration concepts and patterns used in traditional enterprise integration...
Copilot Studio: How to Plan Integration with Enterprise Systems
Integrating Microsoft Copilot Studio agents with enterprise systems transforms a basic chatbot into a secure, intelligent digital teammate tha...
Book Review : The Manager 's Path : A Guide for Tech Leaders Navigating Growth and Change by Camille Fournier
After a long time, I came across a book that is truly valuable for engineering students and professionals, especially those working in t...
Power Platform Environment Deep Dive (Part 2)
In Microsoft Power Platform, choosing the right environment type is important because each environment is designed for a different business pu...
Power Platform Environment Deep Dive (Part 1)
Today, in the business enterpriese world, Power Platform enables organization to build application, automate workflow, analyze data crea...
Book Review : Life 3.0 by Max Tegmark
This is the third book I’ve read this year, and even though I’m still in the early chapters, it already feels like my favorite read of the yea...
Dataverse Views Demystified: Making Data Work for You
In Microsoft Dataverse, users do not always see all the data stored in a table. What they can view depends on their security permissions, role...
Decode & Fix : Shared App host initialization has timed out in Microsoft Power Apps
Issue :While working with apps in the Microsoft Power Platform, we encountered a critical issue where the application failed to load pro...


