When you deploy Canvas Apps and Flows in Power Apps and Power Automate you can choose to deploy them one by one but adding them to solutions is easier.
Solutions
Solutions can contain all sorts of things within the Power Platform in this post I will focus on Canvas Apps and Flows.
So my solutions includes 1 Canvas App and 1 Flow. And I have just exported this app within my development environment.
If your app and flow are now to be imported into a different environment within the same tenant or within a different tenant might or might not matter depending on the connectors used.
If you connect for example to a SharePoint site within your flow you might find that the list that you connect to exists in one tenant but doesn’t within the other tenant as the base urls for the tenants will be different.
On the other hand if you connect to SQL server then your connection to a development database or production database the only difference between the two will be stored in the connection. This is assuming that your database models are the same.
Deploy Canvas Apps and Flows with Connections
Both your Canvas Apps and Flows will most likely be using connections. Connections are the definitions of how you can connect to data sources. When you deploy canvas apps and flows, most likely you will find that the connections are the hardest part of the deployment.
When you import solutions the solution import will ask you for the connection details for each of the connectors used
If you don’t have an existing connection yet, the you can create a connection first.
Once the solutions has been imported the flows and power apps are ready to be used. Although …
This is the point where we should really look at the design of our apps. Or actually this should have been done a lot earlier.
Running the flow
In my example I’m going to deploy my power apps and flows across tenants. If I used the same tenant I would potentiality be able to access my development data in SharePoint from my production app and flow by accident.
The import however wouldn’t give me any failures. For this post I wanted to make the issue as clear as possible.
I’m using two tenant to make the problem even clearer. As i try to turn on my flow, which accesses a test list in by development tenant, I will get the following error:
Your flow could not turn on: test deployment flow. Error: Flow client error returned with status code “BadRequest” and details “{“error”:{“code”:”InvalidOpenApiFlow”,”message”:”Flow save failed with code ‘DynamicOperationRequestClientFailure’ and message ‘The dynamic operation request to API ‘sharepointonline’ operation ‘GetTable’ failed with status code ‘Unauthorized’. This may indicate invalid input parameters. Error response: {\r\n \”error_description\”: \”Exception of type ‘Microsoft.IdentityModel.Tokens.AudienceUriValidationFailedException’ was thrown.\”\r\n}’.”}}”.
Once I’ve fixed my flows I’m able to turn them on.
The Cheap (=Expensive) vs Expensive (=Cheap) way
This kind of deployment through solutions is great but not so great when you try to do this the cheap expensive way.
SharePoint may look like a great datasource as it is part of what we already have and it gives us the feeling of free! But when you look at the deployment process, you mind find yourself spending a lot of time fixing connection issues when you deploy things from development to production.
Just for one moment imagine that you have a list available in the Common Data Services or in SQL Server. Shall we call this list Environment Settings. The Environment Settings could now contain the url of your SharePoint site.
Now all we need to be sure of is that our flows don’t have hard coded urls in them. Other than for flows that are triggered on changes of list item or files, we can first read settings from SQL or the Common Data Service.
Within the rest of our flows we could use REST APIs or Graph APIs if we really have to. See also Create generic flows in Power Automate and SharePoint Rest Aapi in Power Automate for no code developers
My thoughts
Very often I get involved with projects where people created flows and apps and deployment wasn’t the first thought of the development process. The app or flow just had to work. Then as the solution evolved it often takes multiple days to move updates from dev to test to production.
Putting the right architecture behind the Power Platform development does help an awful lot. This will however always be a challenge as the low code and pro code world are coming together.
The steps to deploy Canvas Apps and Flows is just one of those steps where the Citizen development world could do with a bit of help from the pro developers.
Hi Pieter
What about the #projectoakdale version of the story ?
Regards
Nigel
I’ve not looked at that. Maybe in a future post.
Hi, your post was very interesting but I have a question, what is the correct architecture behind Power Platform? In the microsoft documentation they do not talk about that, and the tutorials only focus on how to use the elements and not on the correct way to use them, they are very short and basic, you will not have a tutorial about it or do you know a book about that?
Hi Juan,
Can you give me a bit more detail on what you are after? Personally I think that with the Cloud based systems it is nice to not having to know what sits behind the technology. So for example, I know that Power Automate is based on Azure Logic Apps however I really don’t have worry about that level of the technology at all.
Sorry, I did not explain it well, what I mean is what you comment in your conclusion “Putting the correct architecture behind the Power Platform development helps a lot”.