Microsoft Power Platform Low-Code Services
View All Tags
A flow that has to move to another environment with its app belongs inside a solution. This guide creates an instant cloud flow, one that someone starts by hand, inside a solution, and then opens it in the new designer, which takes one extra step.
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.
Power Automate's expression editor told me This expression has a problem. You can fix it manually or with Copilot. The expression was correct, and the same one worked elsewhere in the flow. Selecting Add again, sometimes two or three times, added it. Once, though, the message was right, and the reason is worth knowing.
I saved a cloud flow, and the action I had open in Power Automate's new designer suddenly showed No additional information is needed for this step, Not connected. and an empty Code view. It looked as if Save had wiped the action. It hadn't: selecting the action again brought everything back.
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.
The app is built. This part tests it the way the brief describes it, as each person in the demo sales team: a manager who's also an employee, a response that's declined and sent again, a promotion, someone who leaves and someone who joins. There are no new screens, only real accounts, real data and three findings.
This part lets managers keep each job title's plan up to date: add a competency, change its level or remove it, from one Competency screen. Every change applies to everyone with that job title, so the screen says so, checks for duplicates, asks before removing, and tells reviewers when a plan changed under a response.
Adding an item and editing one need almost the same screen. Instead of building two, build one and open it in two ways: with the item's ID to edit it, or with a blank ID to add a new one. Each formula that differs asks one question, IsBlank(locCompetencyId).
Some actions deserve a second thought, such as removing something many people use. Instead of acting at once, the button asks a question on the same screen, with Yes and Cancel below it. Nothing happens until Yes, and screen readers announce the question.
