Loading...

How Every Plugin Action Travels Through Request, Service, and the Pipeline

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.

How They Interact in the Plugin Pipeline

The plugin pipeline manages how your logic is executed within Dataverse, with clear stages:
  • 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

Transaction Management & Atomicity

For architects, the biggest concern is ensuring consistency and avoiding unintended rollbacks.
  • Synchronous Plugins (Pre & Post Operation)
  • All service.Execute(request) calls are part of one transaction.
If any request fails, everything is rolled back → ensures atomicity.

Asynchronous Plugins
  • Execute after transaction commit.
  • Service calls are isolated → no rollback of the original operation if they fail.
Architectural Implications:
  • Use synchronous for business-critical & atomic changes.
  • Use async for heavy operations or external integrations to avoid blocking user actions.
Best Practices for Architects
  • 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
Summary:

In Dataverse, every plugin action is a journey that flows through three core components: Request, Service, and the Plugin Pipeline. A Request defines what action needs to happen, like creating, updating, or deleting a record. The Service (IOrganizationService) acts as the executor, performing the action against Dataverse. Meanwhile, the Plugin Pipeline orchestrates the entire process—deciding when plugins run, maintaining transaction control, and triggering downstream operations.

Together, these components ensure that plugin logic is transactional, secure, and predictable. For developers, this means smoother plugin execution and fewer surprises. For architects, it provides a clear blueprint for designing atomic, scalable, and auditable Dataverse solutions.

Published on:

Learn more
Power Platform , D365 CE & Cloud
Power Platform , D365 CE & Cloud

Dynamics 365 CE, Power Apps, Powerapps, Azure, Dataverse, D365,Power Platforms (Power Apps, Power Automate, Virtual Agent and AI Builder), Book Review

Share post:

Related posts

Stay up to date with latest Microsoft Dynamics 365 and Power Platform news!
* Yes, I agree to the privacy policy