All,
I have a Flow that is supposed to copy geometry and attributes from an ArcGIS Online hosted feature class parent record and attributes from a related record to an Enterprise hosted feature class. It is triggered by changing an attribute in the related table. After the record is copied, I have added a step to the Flow to populate a field in the original related table as '1.' This is used in a condition to prevent duplicate copies if the original geometry or attributes are edited in the future.
The problem is sometimes the Flow works. Other times Power Automate says "Your flow ran successfully" but it doesn't actually finish; it gets to the Condition step and spins. In the Run results it shows that there is an error, but "The expression contains dynamic functions, variables or parameters that cannot be resolved in the debugger."
The Power Automate team suggested I try adding another condition to check if the returned array is not empty. However, I've tried several and it still doesn't work. See the attachment. The team is currently working on a release and can't get away to help and suggested I post here since I need immediate assistance.
The function I entered into the window is: empty(outputs('Fetch_updates,_changes,_or_deletions_from_feature_layer')?['body/items'])
Sometimes this function doesn't have an error associated with it (the screenshot shows an exclamation point, but some of my trials don't result in the exclamation point), but the others still do.
Any suggestions? This is really affecting my workflow and will affect it even more because my Tool will see increased use in the near future!
Annina
This is some fantastic insight and explanation! I should be able to set up a little test to try and simulate what you have going on. And you're right, I wouldn't expect edits to the parent to affect the child table unless a change to the child table actually happened. I'll see if I can find some time today to give this a sho
That said, this does sound like a little backwards from what I would expect though. Your environment and specific workflow is likely different from what I am envisioning, but this would be my first instinct:
1) Watch parent layer for changes, and trigger flow accordingly (thought here being that the child/related table should never be updated without the parent).
2 - Option A) Use a value from the parent table in a condition (similar to what you have) to conditionally run Get data from feature layer. If the condition is true, then this part should run as data should be there.
2 - Option B) Simply use a Get data from feature layer action on its own (Option A is best, if possible, as it avoids unessesary calls to Portal). Next, use a compose with something like length(outputs('Get_data_from_feature_layer')?['body/data']) to check if any records were retrieved (value returned will be an integer), then use this output in a condition.
In both cases for Get data from feature layer, you'd do something like Query by field = ParentRowID (from the Child) with Search value = UniqueRowID (from the Parent). You can also toss in a Where clause if needed. Example:
As I said, Esri connectors like to fail gracefully. So even if you go with Option B and no records are returned, this wouldn't fail (at least at this step).
I agree, it does seem backwards, but I think it has to be done that way because the attributes that the Condition uses to run are from the child table.
I tried creating another flow starting with listening to changes in the parent record (because I agree with your theory that a child record wouldn't be updated without the parent), but again, when I click on the run to see what happened, sometimes it shows as expected (look, though, at the ! still displayed next to the Condition result, even though it says "False"):
And other times it doesn't (I included what I think should be happening in the steps in this image):
But, like you've mentioned in the past, the New Designer can be weird, and the old view shows it correctly. So, I tried then making the change to the child record and the Flow didn't run. At all. Even the original Flow (that is looking at the same data) wasn't triggered.
I'm fit to be tied since I have to make the changes manually if the Flow doesn't run or runs incorrectly, but there's not an easy way to identify the changes!