Blog Post

Azure Integration Services Blog
2 MIN READ

Business Process Tracking Reaches General Availability

KentWeareMSFT's avatar
KentWeareMSFT
Icon for Microsoft rankMicrosoft
Jun 10, 2025
Business Process Tracking provides key insights to business stakeholders from your Logic Apps (Standard) implementation in an efficient and timely manner. Today, we are pleased to announce the Genera...
Published Jun 10, 2025
Version 1.0
logic apps standard
r3verse's avatar
r3verse
Copper Contributor
Jun 11, 2025

KentWeareMSFT​ looks like some welcome additions, especially the CI/CD support. But I still have many issues with this product:

  1. It's still very Azure Portal centric instead of a code-first approach. Developers like to build stuff from the ground up in code with a language that's clean and readable, not exporting some generated files via the portal.
  2. 0 mention of Durable Functions support. So what's the point for actual developers? We're not allowed to do business process tracking with durable functions? If this was designed with a code-first approach, you would naturally have support for both Logic Apps and Function Apps, since it's virtually the same engine.
  3. No mention of OpenTelemetry in this product. Even though I am aware OpenTelemetry support just launched for Logic Apps, there is no relation to business process tracking as it seems. OpenTelemetry has a very powerful concept of "Context" in a distributed matter, that would very well be suitable for business process tracking. Now, Business Process Tracking seem to create its own concepts of how to structure business logging, instead of relying on an open standard that is implemented right now in every Azure product. 
  4. "This release is currently optimized for speed." is mentioned in the docs, I'm sure there will be a release that features actual reliability, but it does seem strange that such a product isn't built with reliability in mind initially, especially with business processes. Developers rather sacrifice a few milliseconds for guaranteed delivery and observability. 
KentWeareMSFT's avatar
KentWeareMSFT
Icon for Microsoft rankMicrosoft
Jun 11, 2025

r3verse​ thanks for your post. Will do my best to answer your questions:

1) We have built this feature so that it doesn't require a developer to write code to extract key business data. A Solution Architect or a Business Analyst should be able to define a business process and identify key business data. This is the audience that typically understands what business data is most important to track for business purposes. You should also be able to change your tracking data without modifying code.

 

2) We announced Codeful workflows which are based upon durable task framework. Within codeful workflows, we will support Business Process Tracking. To your previous point, developers will have the option to write this all in code, if they wish. BTW, when it comes to our tracking engine, we have jobs that we attach to that don't exist in Azure Functions, so that is part of the reason why this exists in Logic Apps and not Functions. 

 

4) Reliability is core to our implementation. For this reason, we are leveraging Azure Data Explorer which offers both speed and reliability which is one of the reasons we chose this data source as our backend data store vs some other data stores that are lossy, ADX is not.