Simplified example. New Cloud flow with Manual Trigger and no inputs.
2nd Manually triggered flow that calls the first Flow in a "Run a Child Flow" action.
9 required inputs that were not referenced in the original a trigger. When did this requirement start for Child Flows and is it going to wreak havoc with all of our existing Child flows.
Hello Team, I have another workaround that may be simpler and I hope it can help someone.
Just delete the trigger and create it again with the same input fields. Then run a new parent flow test (do not resubmit a previous test, because this makes the issue again).
Please let me know if you have any questions!.
For those who may come across this thread and wonder if the issue is still there....
This just happened to me as well.
I do not know if I briefly used one of those weird auto-parameters, causing the issue.
I do know I was using make.powerautomate.com with the "New" interface. I won't be using either of those again...
I was about to create a new post about this exact same issue I've encountered. I ran the child flow as a test and the main flow added these required fields. I do not have experimental features enabled in this environment.
So, what was working just fine is now going to take me how long to fix on my own? There seems to be a few different options to resolve this issue so I'll need to take the rest of my day to see which one works without breaking everything. Just another day behind schedule.... Thanks Microsoft!
Hello Team, I have another workaround that may be simpler and I hope it can help someone.
Just delete the trigger and create it again with the same input fields. Then run a new parent flow test (do not resubmit a previous test, because this makes the issue again).
Please let me know if you have any questions!.
Thank you so much for sharing this information! It fixed the issue perfectly. I combined the knowledge of where/how to remove with the Postman update hack (from here) to update the flow without exporting/modifying/importing. Awesome!
Sorry to revive an older post, but since this thread is one of the first results when doing a Google search on this issue, I just wanted to add a bit here that could be helpful for some or at the very least potentially provide some information/context that I discovered. (Really just trying to justify the amount of time I've spent on this...)
I also wanted to note that we recently saw this after enabling "Experimental Features" in this environment (luckily it's just dev). So there is a potential that this is the result of one of those features, and is ultimately self-inflicted pain. If that's the case, then there is the potential for it to be re-introduced upon the official feature release. Or it's entirely unrelated and we just got unlucky. 😉
As other posts have said, this is not so much an issue with the "Run a Child Flow" action as it seems to be with that child flow's "Manually trigger a flow" trigger.
Using the "Peek Code" option on the trigger, I was able to see that indeed certain fields, such as 'key-button-date' and 'location' were being required in the JSON.
The proper working functionality is that if you reference the trigger's various "extra" options such as "Date", "Full address", "Latitude", etc (available by default in the "Dynamic content" popup) within a flow action, these properties get automatically added to the trigger and are required. You can't see them IN the trigger without peeking the code, but they are there.
Now the reason I'm sure we are all here, is that we didn't in fact reference these items within the flow. So the question then becomes how did they get there and why can't they be removed?
From my testing, the best initial description of the issue I can come up with is that those properties have somehow become disassociated with whatever process is used to add and remove them dynamically from the trigger.
Interestingly enough, I was able to go in and create a new "Compose" action where I intentionally added a reference to the trigger's date (aka 'key-button-date'), saved, and then removed the reference. When I peeked the code of the trigger again, the 'key-button-date' property also was removed! I was excited and thought I had stumbled upon a true fix that user's could implement, until I subsequently tested with various location-based fields and had no such success. I tried many combinations of trying to remove whole large objects such as the generic 'address' to small independent fields, such as 'Postal code', and could not get the "fix" to happen again. 😞
I also went into another environment, created a new flow, added all the fields to a Compose action (and thus the trigger) and reviewed the JSON and could not find anything obvious like a property or order change. They also all removed just fine as expected. So I'm really not sure why Power Automate refuses to clean up it's own trigger code in this one specific case.
Anyway... the "true" fix that I did is not the Microsoft recommended fix, and I can't really say if it's more or less risky or annoying than deleting and re-adding a trigger, but for me it made more sense.
I am using Solutions in my environment and I "simply" (relative to your personal experience lol) exported the unmanaged Solution and updated the flow's JSON to remove the offending schema. If you are going to attempt this, you'll need a text editor like notepad++ and for sure a test environment to ensure everything comes back in properly.
Also I would recommend keeping a copy of your unaltered exported solution somewhere, just in case something doesn't seem to be working correctly afterword.
Unzip the exported .zip file, go into the Workflows folder and open the flow JSON in your editor of choice.
The first step - if you aren't 100% sure that you absolutely were not referencing this item in an action - is to do a "Find" for one of the offending items. For instance, if I was referencing the "Latitude" property in my flow, I would see the following "triggerBody()" statement in an action property:
If you find something like this. STOP. Go back into your flow in Power Automate and delete that reference first and see if it clears up your issue.
If you are like me, where the only two finds for 'location' were within the trigger itself, then you can move on to editing the JSON.
You'll be looking for the below data (displayed in VSC for readability) under the "triggers" property. (Truly, your 'location' object will likely be much longer than this, I just recreated a simple example for this screenshot).
You then want to delete everything in the yellow boxes (the entire location object), being careful to ensure you also remove the preceding commas and don't accidently remove an extra brace/bracket. Also don't forget to remove the reference to the location property in the "required" array - also highlighted above.
After doing this, you can save and close that file. Then open the "solution.xml" file and update the version to a newer one:
Then go in and re-zip your solution. Your folder structure should look like MySolution_VersionNumber.zip -> "Workflows" folder, solution.xml + other files. Don't zip at the top level and include an additional parent folder or it won't import properly.
Once that's all done, go ahead and attempt to re-import your solution. If successful, when you edit your flow and peek the trigger code, you'll see the offending required items are gone. Additionally, when you go into your "Parent" flow and view the "Run a Child Flow" action, the extra fields will be gone and will allow you to save without unwanted "required" fields.
Hope this helps someone. 🙂
Yes, I understand the situation and I was frustrated to know that this is the solution proposed by them.
I definitely agree with you because my child flow is very large as well. I have to be very careful to add the dynamic content back to my flow again. Luckily my parent flow does not required any input from the child flow, which saves me the trouble and time to add the dynamic content to each of my parent flow.
Also, I am not sure what kind of help can they provide besides asking for more screenshots of my flow and try this tedious step. If anyone comes up with anything, please share.
I did just test this proposed fix on a smaller child flow, what is failed to be mentioned is that this proposal also requires you to modify ALL of the parent flows referencing the child flow as well since the "Run a child Flow" action is now passing variables to a child flow that are no longer being requested when you replace the trigger action in the child flow.
#1
WarrenBelz
146,695
Most Valuable Professional
#2
RandyHayes
76,287
Super User 2024 Season 1
#3
Pstork1
66,015
Most Valuable Professional
Share
Report
All responses (
Answers (