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 more