The technical ability of Microsoft Power Platform and thus also Dynamics 365 CRM apps to automate your business processes and their data management are unquestionable. Their market presence is huge, and you can find endless customer stories on how organizations digitally transformed themselves with this technology.

Does this guarantee that if you purchase the right set of licenses from Microsoft, all your current and future business process management needs will be covered? Only in the same way as buying a big box of Legos will allow you to construct any building or vehicle imaginable. The pieces offer an exciting and often rewarding journey for the builder who has the vision of how things click with one another. For the bystander, it may look like just a messy pile of plastic. That’s because they cannot observe a shared blueprint of what’s actually going on here.

I believe this divide between what the developers see vs. what the users see is a significant factor slowing down the adoption of new business applications in organizations. In this post I will try to illustrate the practical challenges that arise from this dilemma of the invisible business process buried inside the platform. I’ll also discuss one approach for addressing the issue.

The platform that has it all?

Whether the process data lives inside Dataverse or some non-MS system, you’re gonna have plenty of great tools to connect everything together as a low-code developer. The security models, audit logs, identity management and all the other key capabilities of enterprise level systems are available for the solution designer to pick from the platform toolkit, rather than having to invent the wheels every time. It’s Powerful with a capital P.

How is the end-user experience then? If the technical architecture in MS cloud is a great fit for managing a broad range of business application workloads, what does it feel like for those employees who truly manage the business processes? Meaning: those who are responsible for ensuring that the processes are operationally working as expected. These people get a call when something that another business process or party expected to receive failed to arrive, was late, didn’t meet the specs, and so on.

In theory, Microsoft’s first-party apps in the Dynamics 365 product family are what deliver the experience to the business users. In practice, every real system in enterprise organizations gets heavily extended and customized with the Power Platform tools. This means no outsider would know how the processes really work if they weren’t involved in building the system.

Tools for techies vs. apps for users

Us low-code techies are rightfully excited about all the cool tools Power Platform offers us to build solutions for any kind of process automation, with very little code. However, none of these tools are visible to the business users who are operating the processes. They won’t know the solution architecture and components used. They will only see the application UIs, messages, and reports that the techies have built for them.

This is worth reiterating, to emphasize the great divide:

• A) We, the Power Platform makers, are using tools built by Microsoft. We get to choose from any combination of elements the platform offers (and even extend it via SDK/API).

• B) “They”, the end users, are not using tools built by Microsoft. Their tools come from what we have built, for them. It’s the one specific configuration of elements that have been selected into a unique solution.

The A crowd knows how the system is configured and how it’s supposed to work. They also know where to look for issues when the process runs into an error. Even if they might think some of the MS cloud services are fragile and lacking in certain features, their confidence level is relatively high. Because they see what is happening.

The big question in business applications adoption is end user confidence in the system. I believe it is often a blind spot that is not well understood by those who design and develop the systems. I’m not sure it’s even that well understood by Microsoft that provides the underlying tooling - or as in the case of complex business process management, doesn’t.

Seeing is believing… that everything is working

Until AI one day finally takes over all the tasks that human information workers are responsible for today, someone needs to use the information systems. Open the apps, search for details, enter data into forms, review the state of things. When it comes to business processes that have either a longer duration or that contain steps performed by other users or systems, the frequent questions a user can have are:

• Did the process automation start?

• How is it proceeding?

• Were there any errors?

• What should happen next?

• What are we waiting for?

Surprisingly, the business applications built on Microsoft Power Platform are often not well equipped to answer such questions. Not for the end user, at least. The most common scenarios for error handling have hopefully been explored while the technical design of process automation has been performed during system implementation project. Still, all too often that only leads to additional business logic execution and logging done behind the scenes, away from the user interface.

The fundamental challenge I’ve seen with many Dynamics 365 based systems taken into use across various industries is that they’ve been designed to only meet the technical needs of a business process. Much of the effort in customizing and expanding the CRM systems tends to go into defining what data must be captured in which stage, so that something can happen in an integrated system, in a report, or in a background workflow. Once developed, it is then tested, and eventually deployed to production.

How about the human needs of all the people that get to work with the system? “Oh, we’ll be sure to provide detailed training material for them on how to use the system.” Great. Now the employees must learn both A) how the business process works, and B) how to operate the machine needed for some of its actions. Leaving them with two separate mental manuals to keep open at all times, while also monitoring that the machine behaves in the right way, with the correct inputs and expected outputs.

“But what about this visual Business Process Flow in Dynamics 365 that is all about displaying the process stages? Wouldn’t that be used to manage the process in practice?” Well, it certainly looks cool at first. BPF was a major selling point of the product back in CRM 2013 when it was originally introduced. Customers still often ask it to be enabled - before later realizing that it doesn’t really help them in the day-to-day business process operations all that much.

Because it doesn’t automate anything. It’s mainly a way to split form fields to be shown and required based on the stage value. Yet it’s all entirely manual - unless someone develops automation via other tools in the platform to make the computer work for you.

Inside the engine room

Let’s say that there are automations developed for the system, using Power Automate. Triggering an automated process from the input given by a model-driven app user is typically done in a couple of generic ways. Either the user needs to know which form fields need to be filled with what values to initiate a flow upon the form save event. Or there might be a custom Command Bar button added alongside ten other buttons that needs to be pushed.

How do the users know what happens after a form field value is changed and the form data is saved to the database? They won’t - unless the developer somehow created a mechanism for this. Back in the Dynamics CRM days when process automation was still part of the same platform, the XRM workflow instances that were triggered, running, and completed against a record could be viewed by the end user. Today, no such tight coupling exists between the application UI and the process automation, as Power Automate is a generic tool to connect between any cloud systems with an API.

If the end users have no visibility into such details, what do the developers using Power Automate see about the business processes then? The flow editor does reveal every bit of the logic that gets executed when a flow is triggered. Today, we can try to make sense of it by asking Copilot to explain what the flow does. Certainly a welcome addition to the platform, given how much complexity can be buried inside a more advanced cloud flow.

Alongside the logic, we get a detailed view of how the specific flow has been executed in its recent instances. Process mining capabilities are also today natively plugged into the cloud flow maker experience. We can use these to get a wealth of data from the flow run history to analyze via generated charts:

Seems like there is quite a lot of data visible to the developers then. This is part of the reason why it’s not exactly useful to be revealed to end users. In the end, it’s just technical data about the implementation details of a single flow and a technical log of its execution history.

This leads us closer to understanding the core issue. There is no unified representation of an actual business process in the Power Platform. It doesn’t have a place to live inside the system. The platform can serve as the system of record for things like contacts, orders etc. Flows can perfectly well represent the automation of a sequence of events, like sending a confirmation email to a contact when an order is placed. But where do we step up from that to see what business process these things relate to?

Business process <> flow

A real-life business process can easily span across several different flows. When Microsoft introduced the Power Automate Process license, they publicly acknowledged this reality from a commercial perspective. You can buy one license and then use it to cover N number of flows that make up the complete business process. As stated in the licensing FAQ:

Similar conflicts exists on the app side, too. It is perfectly common to have dedicated app modules or model-driven + canvas app combinations to serve different end user audiences. They all still work with the same business application on a high level, despite of not sharing the same “app”. But in the world of Power Platform, there’s no word for this higher-level business application. It’s not a solution, since obviously a larger system can have several solutions.

The divide between process design and process operation

One could claim that the most efficient way to manage complex business systems would be a world where both the design and the implementation are handled within the same platform. Model-driven Power Apps are a fine example of the benefits from such an architecture approach. As the application is so closely aligned with the underlying data model configured in Dataverse, the low-code app developer often won’t need to think about the database side and the client side separately during the development work. Even as the options for UI level configuration have greatly expanded in recent years, this model-driven approach helps keep things simple enough to manage as the system evolves.

It would be awesome to have something similar on the process side, too. What could “model-driven business processes” look like? For starters, I think they should cover both the automated actions (like cloud flows) as well as expected manual actions from the users. Just like there would be multiple automated sequences of tasks (flows) in the business process, also several different user personas should be supported for the manual tasks. To make it easy for all stakeholders to understand, perhaps the visualization could even be based on a common standard, like BPMN:

Such process diagrams are often created today already, using tools like Microsoft Visio. Because complex business processes need a map for humans to figure out all the moving parts needed in turning process theory into system reality. The problem is this design exercise isn’t directly connected with how the system typically ends up being built. Maintaining a map that provides drill-down into the individual flows is a human task that “someone” would need to do, because the process design and process operation tools aren’t talking to one another in any automated fashion.

As a result, the users who work with the process on a daily basis rarely even know such process visualizations exist. If they did, they’d probably be able to point out many details in the diagrams that don’t match with the reality of the system. Maybe they never did, or the system and process simply evolved after the initial design phase. In any case, closer alignment of diagram & reality would surely help the business to optimize its operations in many ways.

Given how prominent Visio as a tool in the land of process flowcharts, it’s strange that Microsoft has not pursued a vision (pun intended) where these diagrams would be an integrated part of the operational business process management system. Luckily, the extensible nature of MS software products and the global partner ecosystem around them has produced at least one example of what combining Visio with Power Platform can offer: AgileXRM.

In future posts I will be exploring the pros and cons of this process management approach in more detail. In the meantime, you’re welcome to check out my summary of why I think Power Platform customers looking for BPM solutions should start with AgileXRM.