AB-400: Reliable Dataverse Bulk and Background Operations

Introduction

For reliable Dataverse bulk and background operations, choose the unit of correctness before increasing throughput: decide which writes must succeed together, select a supported bulk or individual-request path, bound concurrent work, and retry only failures that can recover without changing the business request. Treat an accepted asynchronous request as pending work until its terminal result is recorded. These decisions form one execution contract; a faster submission rate alone does not establish successful processing.

Use service-protection feedback to pace requests, separate rejected business data from temporary capacity failures, and preserve enough identity to resolve an uncertain response before replay. Dataverse background operations are preview and can detach a custom API request from the waiting client, but they do not increase the invoked plug-in's two-minute execution timeout. Choose another processing boundary when the work itself cannot fit that constraint.

Architecture Overview: Make Completion Measurable

A useful integration design has a durable work ledger, an admission controller, execution workers and a completion observer. These are recommended application responsibilities, not additional Dataverse services. The ledger identifies the requested business change. The controller decides when another attempt may begin. Workers translate that change into a supported Dataverse request. The observer distinguishes submission, success, rejection and an unresolved outcome.

For example, a facilities system might update inspection observations in Dataverse. Each observation can be processed independently, but assigning a repair and recording its allocation may require a shared consistency boundary. Combining both into one large import because they arrived in the same file obscures their different correctness requirements.

Before choosing an API, record these decisions:

Decision	Selection criterion	Evidence the design must retain
Independent write or atomic business unit	Can one record remain committed when another fails?	The intended consistency boundary and failure behavior
Bulk operation or individual/batched messages	Does the target table support the operation, and can inputs be validated?	Capability check and recoverable input identities
Concurrent work	How much outstanding work can this environment and client sustain?	In-flight count, latency, throttling and completed work
Retry or correction	Will waiting change the failure condition?	Fault category, next eligible attempt and retry budget
Foreground or background completion	Must the caller keep a connection open?	Final result or a persisted pending-operation reference

Evaluate performance as confirmed business units per interval. A count of submitted rows can increase while the backlog, retry delay and unresolved operations all grow.

Core Components and Their Execution Boundaries

Select Bulk Behavior by Table and Failure Unit

Microsoft documents CreateMultiple, UpdateMultiple and UpsertMultiple as bulk APIs; DeleteMultiple is available for elastic tables. Verify support for the target standard table rather than assuming that every core table supports every message. Standard-table bulk errors fail the whole operation; elastic bulk operations can report individual failures. These APIs are intended for external clients, not use inside plug-ins.

That difference changes recovery. In the facilities example, suppose an independently valid set of observation updates contains one invalid value. An all-or-nothing operation gives the worker no committed subset to advance. Correct or isolate the bad input before resubmitting the affected unit. With an operation that reports individual failures, retain a result for every input and reprocess only the unresolved or failed items. Never infer which rows succeeded from their position in the submitted list.

When bulk APIs are unsuitable, ExecuteMultiple for the software development kit (SDK) for .NET or OData $batch for the Web API groups messages for transport. Operations within these batches execute sequentially. This is distinct from a bulk message and from a promise that the whole envelope is atomic. Choose and verify transaction semantics explicitly before depending on rollback across requests.

Keep Transaction Scope Aligned with the Business Invariant

Standard tables support relational transactions. Elastic tables do not support multi-record transactions; even a failing PostOperation plug-in does not roll back the created elastic row. Selecting elastic storage solely to accelerate an import can therefore invalidate a design that assumes several writes are inseparable.

For standard-table pipeline processing, synchronous exceptions within the database transaction cause rollback; asynchronous PostOperation steps run outside that transaction. Keep the synchronous portion focused on the invariant that must hold at commit. A later activity cannot retroactively become part of that original transaction.

Consider the repair allocation. If an allocation record is meaningful only when the repair assignment is valid, design those changes around a confirmed shared transaction boundary. In contrast, sending an informational notification can be a separately tracked outcome. A notification failure should produce visible pending work rather than cause operators to believe the assignment never existed. This is a design example, not a claim that Dataverse automatically coordinates external effects with its database transaction.

Large consistency boundaries also enlarge the cost of failure. Prefer the smallest unit that preserves the business rule, and order competing work consistently where practical. Sending many workers to alter the same repair is different from updating independent observations: additional parallelism creates contention and can expose stale business assumptions. Recheck conflicting business state instead of replaying an old decision blindly.

Control Request Concurrency and Retry Together

Dataverse service protection considers request count, combined execution time and concurrent requests per user. The Web API signals throttling with HTTP 429 and a Retry-After delay; the .NET fault exposes its delay through error details. Capacity varies by environment. Microsoft also supplies a recommended degree of parallelization; use that guidance when sizing workers and divide the allowance across cooperating client instances.

Treat concurrency as a shared budget. If four worker processes each apply the entire budget, the resulting load is four times the intended total. A recommended controller keeps a bounded number of in-flight requests, persists postponed items and pauses new submissions for the affected principal when service protection requests a delay. Adding retries to an unbounded queue does not control load.

Tune conservatively against representative data. Record request duration, completion rate and throttling before changing worker count or chunk size. Change one variable at a time. If adding workers raises latency and retry waiting while confirmed throughput stays flat, reduce parallelism and investigate expensive synchronous logic or repeated access to the same records. A nominal request-count ceiling cannot explain all three protection dimensions.

How Components Work Together During Failure

The following policy is a recommended application design, not a universal mapping of every error code:

Observation	Interpretation	Next action
Service-protection rejection with a delay	Temporary admission failure	Persist the delay, wait, then retry within a bounded budget
Validation or permission rejection	The unchanged request cannot currently succeed	Stop automatic replay; correct data, contract or access
Response lost after a write was sent	Commit outcome is unknown	Resolve by business/request identity before resubmission
Conflicting change to the same business object	The original decision may be stale	Reread and reassess the business operation
Accepted background request	Processing is pending	Observe the existing operation rather than submit another copy

For a throttled observation update, preserve the original input identity and scheduled retry time, release the worker slot, and make the item eligible again only after the delay. Recommended retry budgets should include elapsed time as well as attempt count. On exhaustion, retain actionable failure evidence for an operator; do not discard the item or retry indefinitely.

A lost response requires a different decision. Imagine a request that creates an allocation and then loses its connection. The absence of a reply does not prove absence of the allocation. A design that immediately sends a new create request risks duplicating the business effect. Assign stable business identity, define duplicate handling, and provide a way to inspect the outcome. Detailed synchronization and Upsert implementation belong to AB-400: Synchronizing Dataverse with Change Tracking and Upsert.

Check the selected client library's retry behavior before adding another wrapper. Microsoft documents service-protection handling in ServiceClient. Layering independent retry loops can obscure how many attempts actually occurred. Regardless of library, preserve the distinction between temporary transport/capacity trouble and a deliberate business rejection.

Design Considerations for Background Completion

Dataverse background operations remain preview as checked on October 16, 2026. They execute requests implemented as custom APIs. The initiating user needs read/write access to the background operations table. A custom API supplies a named contract with request parameters and response properties; keep that contract stable enough for a completion observer to interpret later.

With the Web API, Prefer: respond-async requests background processing. Persist the returned operation identifier and Location from the 202 Accepted response. Poll the returned status monitor or the background operations table; callbacks and OnBackgroundOperationComplete notifications are alternatives. Completed status must be distinguished from Succeeded, Failed or Canceled. Retrieve result or error information before marking application work complete. Microsoft recommends polling no more often than once per minute.

For the facilities example, a small custom API could produce a bounded inspection summary while the application displays a pending operation. Recommended ledger fields include the application work ID, Dataverse operation ID, submission time, last observed status and final output reference. After a client restart, the observer should resume monitoring the saved operation instead of creating a fresh summary job. These are proposed fields, not a built-in Dataverse schema.

Keep the completion path idempotent: seeing the same terminal result twice should leave the same ledger outcome. Treat an unavailable monitor as an observation failure requiring investigation, not proof that the underlying operation failed. Give prolonged pending work an operational deadline and escalation route without relabeling it successful.

Background execution is a connection-lifetime choice. The two-minute plug-in timeout still applies. If the proposed summary requires an unbounded scan or extensive external processing, reduce its scope or choose an external processing design. AB-400: Azure Functions for Power Platform Workloads covers that separate hosting boundary.

Common Mistakes and Observable Acceptance Criteria

Avoid treating a bigger batch as a cure for slow business logic, disabling validation merely to improve an import benchmark, or counting HTTP acceptance as completion. In particular, bypassing shared business logic can change data correctness for other clients; an optimization requires an explicit, authorized consistency plan.

Verify the execution contract in an isolated development environment with synthetic records and an appropriately scoped integration identity. The following are proposed observations, not executed tenant results:

Place an invalid observation among valid inputs. Confirm the documented atomic or partial-failure behavior and that the ledger records every affected input accurately.
Simulate a throttling response at the client boundary. Confirm that no eligible retry occurs before the stated delay and that deferred work does not consume active worker slots.
Interrupt the client after submission. Confirm that recovery inspects known work before replay, with no duplicate allocation.
Reject a repair through synchronous validation. Confirm that the intended transaction leaves no inconsistent repair/allocation pair.
Return a failed background result after acceptance. Confirm that the interface and ledger show failure with diagnostic evidence rather than success or permanent pending state.

Observe worker limits across all running instances, not only within one process. After testing, stop workers and observers, reconcile outstanding test operations, and remove synthetic business records and temporary access according to the environment's retention policy. Protect fault logs from exposing payload secrets or personal data.

Certification Relevance

The frozen AB-400 scope verified October 15, 2026, effective October 16, includes API retry policies, performance, concurrency, transactions, bulk operations and background logic within Extend Microsoft Power Platform. This guide connects those topics through one outcome: a request-execution design whose completion and recovery behavior can be explained. It makes no claim about live exam availability beyond that dated scope baseline.

Conclusion

Choose correctness boundaries and supported operation semantics first, then measure concurrency and retry behavior against confirmed outcomes. Preserve uncertain writes for reconciliation and accepted background work for observation. The integration is reliable when it can explain what committed, what failed, what remains pending and what may safely run again.