Finance | Project Operations, Human Resources, ...

Correlating an Azure DevOps Release deploy with its msprov_operationhistory record?

(2) Share

Report

Posted on by RSD

We're building an Azure DevOps Release pipeline for a Finance & Operations (UDE) environment. Deploys can take well over an hour, and our team is required to cancel the pipeline stage after a few minutes to avoid burning the client's consumption (the deploy itself keeps running server-side regardless). So we built a separate mechanism to confirm the real deploy outcome asynchronously, by polling the msprov_operationhistory table in Dataverse (filtering msprov_name eq 'Deploy') and reading its statuscode.

The problem

We have no reliable way to know, from the pipeline side, which msprov_operationhistory record corresponds to our specific deploy attempt — especially if two deploys to the same environment happen close together (e.g. a retry after a cancellation).

What we've already ruled out

PowerPlatformDeployPackage@2 doesn't expose CorrelationId or AsyncOperationId as an output variable.
msprov_operationproperties (the JSON blob on the record) contains a PackageName, but it's not unique per run — the same filename gets reused across unrelated deploys.
Auditing is off by default on this table, and even if enabled, wouldn't retroactively help, and doesn't add a controllable/unique value anyway.
The "Execution Id" GUID printed in the Deploy Package task's own console log does not match either CorrelationId or AsyncOperationId on the resulting Dataverse record.

Our current fallback, and its limitation

We filter by msprov_startedon ge <timestamp>, using the timestamp our pipeline queued the deploy attempt (via the Release REST API). This narrows the window a lot, but doesn't fully rule out a genuinely concurrent deploy to the same environment landing a more recent record in that same window.

Is there any supported field, output variable, or API (existing today, even undocumented) that lets a calling pipeline learn the CorrelationId — or any other unique identifier — of the msprov_operationhistory record that a specific PowerPlatformDeployPackage@2 execution will create? Either synchronously as a task output, or via a lookup we're missing?

Thanks in advance for any pointers.

Categories:

Dynamics 365 Finance

All responses (3)

Answers (0)

Sort by

Suggested answer

Assisted by AI

SajeedMullaji 858 on at

Like (1)

Report
Copy link

Link copied!

@RSD
No ,there is currently no supported output variable, native parameter, or API response from PowerPlatformDeployPackage@2 that returns the Dataverse CorrelationId or msprov_operationhistory primary key back to the calling pipeline.
The Execution ID in the DevOps console log is a client-side identifier used by the local Package Deployer runtime — it is entirely decoupled from the server-generated CorrelationId and AsyncOperationId created in Dataverse. The task intentionally swallows the underlying Dataverse API responses and does not surface them as pipeline output variables. Microsoft acknowledged this in GitHub issue #209 for powerplatform-build-tools.
The workaround — Build ID Injection pattern:
Since you cannot retrieve the ID from the deployment task you must force the deployment to send a unique identifier to Dataverse that you can query later. Make the package name unique per pipeline run.
Step 1 — Inject Pipeline Run ID during build:
Do not use a static package name. Dynamically append the Azure DevOps Build.BuildId or a generated GUID to the package name during your CI build phase.
Example: FandO_DeploymentPackage_Run$(Build.BuildId).zip
Step 2 — Deploy the uniquely named package:
Pass this to PowerPlatformDeployPackage@2. The Package Deployer submits this exact string to Dataverse.
Step 3 — Query Dataverse post-deployment:
Add a PowerShell task invoking the Dataverse Web API:

GET [OrgURI]/api/data/v9.2/msprov_operationhistories?$filter=contains(msprov_packagename,'FandO_DeploymentPackage_Run12345')

Because the Run ID is mathematically tied to the specific pipeline attempt this query returns exactly one record — no timestamp guessing, no race conditions, deterministic correlation every time.
This approach holds even if two deploys to the same environment happen concurrently because each carries a unique BuildId in the package name.

If it helps, Mark as answered.
Anton Venter 21,223 Super User 2026 Season 2 on at

Like (3)

Report
Copy link

Link copied!

@SajeedMullaji
I marked your reply as AI-assisted as it seems to be the case. If using AI to answer posts, please remember to enable the "Mark reply as AI-assisted" checkbox before posting so that the source is clear to everyone.
RSD 12 on at

Like (0)

Report
Copy link

Link copied!

@SajeedMullaji Thanks for the detailed suggestion!
Unfortunately it doesn't quite apply to our setup: we're deploying to a UDE environment via PowerPlatformDeployPackage@2, and the actual "Package File" input points to the cloud package's TemplatePackage.dll (produced by XppCreatePackage@2 with CreateCloudPackage: true), not a freely-renameable .zip.
There's no exposed parameter on that task to control the .dll's filename, so we can't inject a unique Build ID into it the way your workaround describes.
We ended up mitigating the practical risk instead: rather than reading the most recent msprov_operationhistory record after our release's deploy started, we now read the earliest one at or after that timestamp. That narrows the window enough for our case (a second unrelated deploy to the same environment would have to start in the few seconds/minutes between our deploy queuing and actually landing in Dataverse to be misread).
It's a mitigation, not a true fix - the original question about a real unique identifier for the resulting record still stands if anyone has one.