I started this project with a simple goal: learn more about Parent and Child Flows in Power
Automate.
The application itself was pretty straightforward. A Canvas App wrote data to a SharePoint list. A cloud
flow was triggered whenever a new item was created in that list, and the flow then called a Child Flow that
sent an email notification. Everything worked exactly as expected.
My original plan was to focus entirely on Child Flows.
That plan changed almost immediately when I discovered that Child Flows can only exist inside a
Solution.
I couldn't learn Child Flows without learning Solutions first.
Once I moved the Canvas App, Parent Flow, and Child Flow into a Solution, a new question appeared almost
immediately.
If Solutions are designed to package applications and flows together, how are they supposed to be deployed
to another environment?
That question ended up teaching me far more than the Parent and Child Flows ever did.
The first step was exporting the solution as a managed solution and importing it into a separate Production
environment.
During the import process, Power Platform prompted me to map SharePoint and Outlook connections. This was my
first real exposure to Connection References beyond simply reading about them in documentation.
Up until that point, I understood the concept but hadn't truly appreciated the practical value. Once I
watched the import wizard map the connections, it finally clicked.
Connection References solve a very specific problem.
They answer the question of who connects to a resource.
Instead of updating every SharePoint action and every Outlook action in every flow, the solution could
simply use a different connection when deployed to another environment.
That was my first ALM lightbulb moment.
The next challenge appeared almost immediately.
Even though the connections could change during deployment, my flows still pointed to a specific SharePoint
site and a specific SharePoint list. The connections were portable, but the resources were not.
That's when I started experimenting with Environment Variables.
I created variables for the SharePoint site URL and the SharePoint list name and modified the flow trigger
to use them instead of hardcoded values. After exporting and importing the solution again, Power Platform
prompted me for those values during deployment.
Another lightbulb moment followed shortly afterward.
As I worked through the deployment process, I started to see the distinction between Connection References
and Environment Variables. Connection References solve the question of who connects to a resource, while
Environment Variables solve the question of what resource should be used in a particular
environment.
At that point, the flow architecture was becoming surprisingly flexible.
Unfortunately, the Canvas App wasn't cooperating.
Even after importing the solution into Production, the Canvas App continued pointing to the original
SharePoint site and list. The flows were becoming environment-aware, but the app datasource remained
stubbornly attached to the original location.
I thought I had found the weak spot in the design.
To make the experiment more realistic, I decided to build separate SharePoint sites for Development, Test,
and Production.
I created three sites:
• HumanResourcesDev
• HumanResourcesTest
• HumanResourcesProd
Each site contained an identical SharePoint list named HR List.
This immediately felt more like an enterprise deployment model. Each environment had its own data while
maintaining an identical structure.
While exploring Environment Variables, I stumbled across an option I had never used before.
Data Source Environment Variables.
Instead of storing text values, these variables could represent SharePoint datasource connections, including
SharePoint sites and SharePoint lists. Curiosity got the better of me, so I started experimenting.
I created one datasource variable that represented a SharePoint site and another that represented a
SharePoint list. I then modified the Canvas App datasource to use those variables instead of the hardcoded
SharePoint list it originally referenced.
This turned out to be the breakthrough I had been searching for.
When I exported the solution and imported it into Production, Power Platform prompted me to select the
SharePoint site and SharePoint list for the Canvas App datasource.
Suddenly the app became configurable during deployment in the same way as the flows.
Instead of editing the application after deployment, the datasource could be configured during
import.
Exactly what I had been trying to accomplish.
Of course, this project wouldn't be complete without at least one classic Microsoft moment.
When the time came to select the Production SharePoint site during import, the site wasn't listed in the
dropdown.
The site existed.
I could browse to it directly.
I had permissions to it.
It simply wasn't there.
Because Microsoft.
After a bit of experimentation, I pasted the Production site URL directly into the field, ignored the
warning, and continued with the import.
The import succeeded without issue.
Sometimes practical experience means learning which warnings can safely be ignored.
Just when I thought I was finished, another problem appeared.
The Canvas App form became stuck displaying "Getting your data..." and refused to load properly. After some
troubleshooting, I explicitly published the app and added a NewForm() call to the screen's OnVisible
property.
One or both of those changes resolved the issue and the form immediately returned to normal
operation.
The final test was simple.
I opened the Production version of the app, entered a record, and clicked Submit.
The item appeared in the HumanResourcesProd site.
The flow triggered.
The Child Flow executed.
The email notification arrived.
Everything worked exactly as intended.
Looking back, it's funny how this entire project unfolded.
I never set out to learn Application Lifecycle Management.
I simply wanted to understand how Child Flows worked.
Because Child Flows require Solutions, Solutions led me to managed deployments, managed deployments led me
to Connection References and Environment Variables, and those discoveries eventually led me to Data Source
Environment Variables and environment-specific SharePoint sites.
The entire ALM journey started because of a single prerequisite I didn't fully understand when I
began.
Along the way I gained hands-on experience with managed solutions, solution upgrades, Connection References,
Environment Variables, Data Source Environment Variables, environment-specific SharePoint sites, and
deployment patterns that scale far better than hardcoded configurations.
By the end of the project, I had learned several valuable lessons:
• Connection References solve the question of who connects to a resource.
• Environment Variables solve the question of what resource a flow should use.
• Data Source Environment Variables allow Canvas Apps to participate in the same deployment model.
• Separate Dev, Test, and Production data sources create a much cleaner architecture.
• Most of the learning happens while troubleshooting the parts that don't initially work.
More importantly, the project reinforced a lesson that seems to appear in almost every technology lab I
build.
The most valuable learning rarely comes from following the instructions and watching everything work
perfectly.
The real learning begins the moment something breaks and forces you to understand why.
Not bad for a project that originally started as a simple exercise on Parent and Child Flows. 🐦🐦