Before every new software was built in the cloud, it was kind of a big deal to offer product-level integration between different business applications. You had to consider the diverse types of environments into which the software components could be installed, and how they could reliably communicate with one another under such circumstances. It’s no wonder you needed an army of IT professionals and consultants to design, develop and operate integrations that transferred data across systems used by the business.

What does it take to achieve business app integration these days? In theory, it’s possible for any maker to make data flow across cloud systems. Even a citizen developer could do it. If, on the other hand, you’re a software vendor that wants their product to talk with all major vendor systems used by your customer base, the theoretical possibilities are also endless. As long as there’s a modern API available on the other side, how hard could it be to make a few calls back & forth?

These days you might as well ask a GenAI chatbot to produce the “integration” code for you. Then, ask another Copilot style LLM assistant to retrieve all the vendor logos and add them onto a PowerPoint slide pitching your software. You’re not technically lying with this approach. The connectivity possibility is there - and business decision makers often won’t be qualified to question the viability of the technical solution.

Not every partner solution with Microsoft Power Platform or Dynamics 365 CRM integration capabilities is the same. Yet it can be hard to articulate exactly what makes the depth of integration different - especially if you don’t have hands-on experience from the MS BizApps solutions. In this article I want to illustrate the broad spectrum of what it can mean in practice to connect third-party services with your business apps on the MS low-code platform.

Integration scenario: payments via Stripe

To understand what a lightweight “integration” option may look like today, let’s explore a scenario where the business wants to use Stripe payments and/or invoices together with their business app running on Power Platform. When a tech savvy business user is looking for a solution, the first thing they’ll check is whether Power Automate cloud flows have a built-in connector for the third party service. In the case of Stripe, there already is a connector. “Awesome, looks like this will be easy to automate!”

Not so fast. Just having a connector doesn’t mean you can do what you need for your business processes. In the example above, the Stripe connector (built by Microsoft) for Power Automate supports 5 actions. None of them are related to payments. Whereas the Stripe connector in a competing automation platform, Zapier, offers 18 standard actions that include creating payments, payment links, invoices, subscriptions. Hmm, why are these connectors so different?

MS initially built a few connectors for Power Automate and Power Apps themselves, since they couldn’t launch an empty platform. Today, all the connectors need to be built either by the party with whom your wish to integrate (Stripe) or community members (Independent Publisher). In this case, it was enough for MS to get the Stripe logo in their slide decks to demonstrate how they support a broad set of 3rd parties. The 5 actions in the connector aren’t gonna meet many real customers’ needs for working with Stripe, but “it is what it is”. My guess is this avoids MS some legal headaches by not supporting actual payment transactions with Stripe.

That’s why we have MS partners, though. On the connector side, there’s not going to be a business case for anyone to build a better version for Stripe API calls. Claiming a fee for such an integration between MS and Stripe would be challenging. There is, however, another avenue available for partners: Microsoft AppSource. If we go and search for “stripe”, there are one hundred results:

Out of those 100 hits, one product offers a subscription-based Stripe integration with a custom Power Apps model-driven app. With zero reviews and no public information on pricing, the barrier for jumping into implementing your invoicing transactions on top of such a product is a bit high, though.

A citizen developer would just subscribe to Zapier at this point and build the necessary automation logic. A more advanced low-code maker aware of Power Platform capabilities could build a custom connector on top of the Stripe API to make the necessary HTTP calls. Talking with Copilot or ChatGPT should give them sufficient guidance on how to achieve the desired payment integration for their business app.

Is this just an “integration”, though? Will it be reliable enough for processing financial transactions that are at the core of business operations? If you’re just using cloud flows to push data back & forth, does the logic handle errors in a way that allows you to recover from them? What kind of monitoring did you build for the process? Most importantly: is it secure enough to use on a shared low-code platform? Keep in mind that Copilots may soon be accessing the same data and connectors, and today they are inherently vulnerable to LLM prompt injections, for example.

It’s super quick to connect REST API enabled cloud systems together in “any-to-any” style - at least for demo purposes. If that’s enough for adding a logo onto your slide deck about integrations, go for it. As for the customers who are viewing such marketing materials, trying to figure out what level of capability really exists behind the logo can be tricky. It could just mean that some data can technically travel between two systems. Whether it serves your specific business needs, who knows?

Platform scenario: BPM for Power Platform

Let’s look at a different end of the partner app spectrum: building on the platform - instead of just integrating with it as one of the many APIs. The example here is business process automation (BPM) and dialogs product called AgileXRM that I’ve mentioned earlier in my newsletter. (Full disclosure: Niiranen Advisory has a partnership agreement with them.)

The company has been in the Microsoft business applications for quite some time already, hence the “XRM” part in the name. How this presents itself in the product today is that the primary user interface for the business processes is through Power Apps / Dynamics 365 CRM. BPM tools are typically applied for long-running complex processes and each instance of such a process will be represented as a row in a Dataverse table called “AgileXRM process”. Thus, they can be browsed via views, charts, and dashboards in the model-driven app for process admins that manage the day-to-day operations:

While staying within Power Apps UI, we can drill into individual process instances, and onto the actual business records like cases in this example. What this means is that from an end user perspective there is just a single application to use. Those who perform the operational activities around cases will have one additional tab on the case form to click on. It doesn’t take them outside Power Apps into an external, integrated system - all the process flow details remain in the context of the primary business application:

“But wait! Is all of that data really in Power Platform?” No, not all of it. There’s just enough of it inside the Dataverse database natively to make the useful features available inside the model-driven Power App / Dynamics 365 CRM user interface. Meaning, you don’t have to worry about the scarce resources of Dataverse storage capacity being consumed by hidden logs of an ISV solution. The AgileXRM specific resources that make the actual BPM engine run are hosted elsewhere. Either in public cloud, customer VMs or on-prem (see deployment options for details). The process design tools, on the other hand, are implemented as an add-in for the Microsoft Visio PC client application.

The features and user experiences of the product are specific to Power Platform as that’s the only place where users will be leveraging it. You don’t therefore need to work with generic API actions and try to figure out how things like status codes, BPFs or activities work in Dataverse. The product comes with opinions on how things will work in the best way for the typical BPM scenarios. It doesn’t try to force a competing platform’s ideology onto MS BizApps. Things like Power Automate cloud flows can perfectly well be a part of the bigger process automation story, since there’s no need to replace or replicate the parts of Microsoft’s platform that will be available for all customers anyway.

Betting on a platform

It’s cool that connecting the dots between different cloud services can be done so easily today that even citizen developers are empowered to build lightweight “integrations”. While Power Automate is more aimed at automating business processes, you could implement similar logic and API connectivity through Azure Logic Apps to achieve a bit more robust solution for integrating business systems. Starting with a quick PoC built on cloud flows and then getting Azure devs involved if you need to take it further is a perfectly valid approach for creating customer specific integrations.

When it comes to products that promise connectivity with other systems on behalf of you, things are different. Since it’s not the customer who’s responsible for doing the dirty work of setting up the pipelines between APIs of different systems, you need to pay close attention to how the pipes fit your specific business needs. Like with physical facilities, it’s not exactly enough that you can tick the boxes for “electricity: yes”, “water: yes”, “heating: yes”, “internet: yes”. If the wall plugs and faucets aren’t where you need them to be, if the place freezes in wintertime, if the payment terminal won’t stay online - it’s not ready for your business. Without inviting some professionals over to do more work for you to fix these gaps.

In B2B software products, there are two distinct business strategies we commonly see:

In case A, there is the incentive to get as many integration logos into your product’s marketing pages as possible. The broader the network of other apps you can connect with, the more valuable your own app product becomes. This means the vendor often wants to remain neutral and not commit to a single “mega platform” (like Microsoft, Salesforce, etc.). The resulting services will be loosely coupled. Customers need to be alert when evaluating what is and isn’t supported, as the devil is always in the details.

Case B is about providing as much value as possible within the chosen market. The vendor commits to solving the problem for a particular niche on a specific platform, such as Microsoft’s. The example of AgileXRM shows the path of tight coupling. Such products tend to be designed with detailed awareness of product gaps and platform constraints, while remaining closely in sync with the plans of the mega vendor to evolve its offering. Any one customer is unlikely to be the first one who needed certain capabilities, thus the path to achieving business value from technology tends to be shorter than when combining loosely coupled products.

Those partners that have built on the platform for several years and gone through various iterations of product, branding, and channel strategy from Microsoft - they tend to be the safest bets for customers. Instead of chasing every shiny new feature, they’re more often playing the long game with the chosen platform and ecosystem. Just like smart customers should be, too.