Microsoft Power Apps Canvas Apps, Power Fx Formulas, and Controls
View All Tags
The app and its setup flow both work. This part turns them into four files anyone can install: both solutions, checked, at version 1.0.0.0, as managed and unmanaged zips, and without this tenant's SharePoint site and lists inside them.
When you export a solution, its environment variables' current values go into the zip, so everyone who installs it gets your values. This guide takes them out with the Power Platform CLI: unpack the managed and unmanaged exports together, delete the value files, and pack both zips again.
Exporting turns a solution into a zip file that another environment can import: managed to install it, unmanaged to keep developing it. This guide exports the same solution both ways, with the same version number, and then does it with the Power Platform CLI.
The solution checker reads everything in a solution against Microsoft's best-practice rules and lists what it finds, each with a severity and a link to guidance. This guide runs it in Power Apps, reads the results, and runs the same check from the Power Platform CLI, whose result file also says which control each issue is on.
An exported solution is an ordinary zip file. Listing what's inside shows what you're about to share: its version, whether it's managed, and anything that shouldn't travel with it, such as your environment variables' values. This guide does it in a terminal on macOS, Linux and Windows.
I set an environment variable's Export value to No and saved. When I opened the variable again, the switch said Yes, and the exported solution still held my SharePoint site's address. The switch can't be trusted on its own, the zip file is the real test, and the Power Platform CLI takes the values out.
The app needs two SharePoint lists with exact column names, and so far they exist only because Part 2 made them by hand. This part builds a Power Automate flow that creates both lists, their settings and all 16 columns on any site, and that can run again without changing anything.
An object can belong to more than one solution, and sometimes it ends up in one it shouldn't. Remove from this solution takes it out of that solution and leaves the object itself, and every other solution it's in, alone. The command next to it deletes the object everywhere, so it's worth knowing which is which.
A flow in a solution doesn't connect to SharePoint directly. Each action points to a connection reference, and the connection reference points to a connection. When the solution is imported somewhere else, whoever imports it picks a connection for each reference, and the flow works there. This guide creates one inside a solution, before the flow that uses it.
I created a cloud flow from inside one solution, and the flow's details page said it belonged to two. The second one was my preferred solution. Microsoft documents why, and the fix moved the flow to a single solution without deleting anything.
