Why Power Platform Pipelines isn't powerful enough for many pro projects

Unpopular opinion - I believe that Power Platform Pipelines (PPP) isn’t powerful enough for many pro projects.

But why?

Only 1 solution at a time

Many more complex D365 and Power Platform projects will end up with several solutions. But PPP can only handle 1 at a time.

As a workaround, we can set up each solution separately but there are some challenges with this:

• How do we record the version of each in the set of solutions that have been tested together when it’s time to cut a release?
  With methods that can handle several solutions together, this is automatic. When we cut a release, we get a single version number/name generated and assets for all of the solutions together.

• I have several/many solutions - how do I ensure it’s easy to deploy all the solutions and that they are deployed in dependency order?

  Best practice refresher: Solutions should always have a defined order in which they will be deployed and therefore in which dependencies between components are allowed.

  If I have to trigger the deployment of each solution separately, the onus is on me to get the order right. Not deploying strictly in the same/correct order can lead to differences in behaviour in each environment as well as for the development team to have a poor understanding of how the dependencies should be structured - leading to uninstallable systems (sets of solutions that can never be installed into a clean environment due to dependency cycles and other issues).

  By contrast, with other methods handling all the solutions together, they can be configured to deploy in the correct order. Deploying always in the right order resolves the issues mentioned above.

Can only handle solution-aware components easily

The components you can put into Power Platform solutions are not the only thing your app/system/process/whatever relies on to be in place for them to work correctly. Omitting these from automation and handing them manually often doesn’t scale .

So it is best if you can version and deploy other assets with your solution(s) like:

• system/reference data

• system settings like enabling auditing, modern business units etc

• creating business units, teams mapped to your security roles in the right business units

• Azure resources your solution depends on (are logically part of your system), like AppInsights or the Functions used by your Custom Connector.

• data migration actions like moving existing data from one place to another as your schema evolves.

PPP can only handle the components that can be part of a solution. So it can’t handle these examples out of the box.

There is the facility to extend your pipeline using Power Automate but Power Automate can be awkward for the types of actions you typically might need to perform - except really simple ones like creating a small number of records. This is because there aren’t many Power Automate connector actions that align well with these.

For instance:

• versioning a complete set of reference/system/config data in a maintainable way is not straightforward.

• imagine you’ve just made a change where you have replaced a choice column with a lookup column. You need to migrate the data that is already in the old column into the new column by doing a lookup for each record. Mass updates like this are quite hard to implement efficiently in Power Automate.

• there are no connector actions for managing Azure resources (outside of a few small use cases). You could hack this together with HTTP with Entra ID actions calling the Azure RM API, but it is quite complex to implement when compared to other tools like BICEP.

By contrast, with other methods like Azure DevOps Pipelines and GitHub Actions, you can use a whole library of tools created by MS which are well suited to these types of actions. If there isn’t something existing, you can write a script and include it in the pipeline. For instance, MS provide the PAC CLI which can be used to import and export “Configuration Migration” datasets.

No Pipeline Versioning

Once you start holding more than just a single solution and the components that solutions can contain, it becomes important that the actions in your pipeline are versioned with your other assets. It’s also of particular relevance if you need to maintain the production version making some hot fixes in a branch whilst still being able to continue your next set of big changes separately. If I add a step to what happens when I deploy like adding a new solution, I only want that to happen from version X of the project onwards. So it’s important the actions are versioned with everything else.

PPP does not make this easy. The Power Automate PPP customisations to the post-deployment actions can only run a single Cloud Flow. Sure, you could put some conditions in there based on version somehow but there’s still always going to be the risk that editing this will break something for the older versions. Why is this important? Retaining the ability to redeploy your older version is often a good rollback plan.

No Source Control

Source control (for instance Git repos in Azure DevOps) if used correctly is your “who/why/when-dunnit?” system - When did we delete column X from table Y and what was the reason? It allows tickets (stories, bugs, etc) to be linked to the changes you are making and you can then look back through history to answer such questions.

Source control also allows you to accurately answer the question about what has changed between version A and B without relying on people’s memory or record keeping. So it can answer the question about exactly what changes you are about to deploy.

I’ve lost count of the number of times source control has saved me. For instance, reminding a stakeholder that we deleted X because they asked us to 3 months ago and jogging their memory about why.

PPP does not offer source control integration out of the box. It is possible to use the Power Automate PPP customisation mechanism to add source control by calling an Azure DevOps Pipeline or GitHub Actions Workflow, but at that point with the complexity involved, you might as well switch completely to those platforms.

So who should use Power Platform Pipelines?

PPP is a great solution for individual makers working on non-business critical systems. Typically a bit of downtime for these systems isn’t significant.

When you have a larger team working on a more complex and business-critical system and that system will continue to evolve, the cost of any extra downtime and development overhead is magnified. For these systems, the extra effort it takes to set up AzDO Pipelines or GitHub Actions and automate more of your critical steps should be more than justified. It enables you to deploy more frequently for feedback, and to deliver value more quickly into production with less overhead and time spent wondering why your feature doesn’t work in environment X.

PPP does as of recently promote a hybrid setup where if you want more complex customisation, you can make it trigger a GitHub Actions workflow. This does improve the flexibility, but I believe if you are at that point, you should just switch fully.