Run a Child Flow Action now has required Fields. Date, Full Address, Country, City, State, Street, Postal, Latitude, Longitude

[daxjkent]

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.

[manuelstgomes]

Hi @daxjkent 

That doesn't make sense indeed. I smell a bug or something that went wrong in a deployment from Microsoft's site.

I tried to replicate the issue on two tenants, and all is ok, so it's probably something that we need to wait for Microsoft to solve. I know it sucks, but the alternative is to contact the support and check if they can help.

Cheers
Manuel

------------------------------------------------------------------
If I have answered your question, please mark it as "Accept as Solution." It will help other members find the solution faster. If you like my response, please give it a Thumbs Up. ?
Otherwise, reply to it, and the community will do its best to help you.

[DKassian]

I am getting this same behavior in multiple environments, along with a bunch of other flow bugs (actions not loading, formula editor not loading, error accessing local storage notification). 

I suspect once again Microsoft has pushed updates without understanding the implications or properly testing. I have not seen any impact to existing child flows, it is only impacting new flows - hopefully it stays that way.

[Anonymous]

Thanks for raising this. I thought it was only me that encounter this issue. 

In my flow, the location parameters are not required but an error still pops up saying that they are required. 

[keithmcclungeip]

I have the same issue. I've found that by using the trigger "PowerApps V2" instead of "Manually trigger a flow" you can run the flow as a child without all the other fields being required. May not help you if you specifically need it to be manually triggered however.

[daxjkent]

Thanks for the suggestion.  This is some super heavy modification in some flows when the variable from the trigger is used thru the entire flow.  

Ideally Power Automate could just get their quality control working better and not inflict these random issues that cause massive mayhem and disruption in production environments.

[daxjkent]

I've had to resort to this in a pile of flows just to get them running again.

[joelzehring]

We're also experiencing failed flows related to this issue.

[Anonymous]

Microsoft support just came back to me and the solution they proposed is working now. What they proposed is that you have to remove the trigger of the childflow and add it back again. 

Yes, I agree it's tedious because I am doing the same thing as well. 

Please mark this as a solution if it works for you as well. Thanks! 

[daxjkent]

Yes we were informed of this "solution" as well, but we will not be doing this due to the size of some of the flows infected. 

Please keep in mind, in order to remove a trigger action, you must remove all references to that trigger action thru the entire flow.  In larger flows this is essentially a complete dismantle and rebuild of what was previously a properly working flow.  The old adage of "if it aint' broke, don't fix it" comes to mind.  It was never the child flow that was the issue, it was the parent flow calling it.  The fix needs to happen at the parent level in order for it to be considered resolved in my eyes.

[daxjkent]

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.

[Anonymous]

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. 

[FinderFees]

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. 🙂

[AbigailRRausch]

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!

[Yrisson55]

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!.

[autopower]

I just got hit by the very same bug now. I guess I will just need to recreate the trigger then.

[anthonys123]

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!

[LenC]

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...

[LenC]

Worked... Thanks!