I'm already sitting the second day on a problem I can not solve - I want to configure the Custom Connector to reach Azure Function from my MS Flow. Configures the FA, generates a proper API Definition (tests Postman as well as from the level of this OpenAPI configurator in AF), exports to PowerApps + Flow, setup connection and ...in MS Flow blocks appear, can be picked but once tested out it failed:
InvalidTemplate. Unable to process template language expressions in action 'GetHttpTriggerCSharp1' inputs at line '1' and column '2484': 'The template language expression' json (decodeBase64 (triggerOutputs (). Headers ['X-MS-APIM-Tokens']) ) ['$ connections'] [' shared_translationcc.5f936381b248f60c56.5fe58c2ca0f3b6e6ce '] [' connectionId ']' can not be evaluated because property 'shared_translationcc.5f936381b248f60c56.5fe58c2ca0f3b6e6ce' does not exist, available properties are 'shared_office365'. Please see https://aka.ms/logicexpressions for usage details. '.
Unfortunately publishing the connector does not help.
I will be grateful for your help.
Solved! Go to Solution.
Interestingly enough... I just ran across this issue 1year later and had to look up the solution here.
+1 for the community!
-1 for the bug still existing!
Grrrr... deleting then recreating the Connection worked... for a while. Then: BAM! more fun.. Unfortunately, these Flow takes photos from a PowerApp and creates a beautiful PDF from them... until this error hits. Then the PDF is not good. Its very difficult to recover these photos. I have to download the raw base64, convert it manually, save the photos to SP, then manually run the PDF Flow again...
I have been fighting this one all afternoon - Powerapp on a android tablet calling a flow.
Note that the flow is continually being developed and this is where the issue seems to be eminating from;
If you look at the error you will see it cannot evaluate shared_commondataservice_1 - but shared common_dataservice is available.
To fix it I did the following.
1. Export the flow (zip file)
2. Removed the common data service connector from the environment.
3. Add the common data service back into the environment.
Then the real fix.
Open the exported zip file and navigate until you get to here
In all three json files do a replace of shared_commondataservice_1 to shared_commondataservice
At the bottom of definition.json you may need to remove a duplicate of
I'm also getting this error on a very complex flow that will take many hours to rebuild from scratch. Two years on, and MS still hasn't fixed the issue.
Hey, Microsoft, this is what happens when you don't bother testing your products before releasing them. Your user base is not a valid QA team!
In my case, I solved it, by recalling the flow action.... delete the code in powerapps that's instatiating that action and do it again... so that powerapps can "refresh" the call
Unfortunately, removing and rewriting the code that calls the flow in PowerApps isn't always an option. In a couple of my apps, flows are called from PowerApps—in a few cases multiple flows in one process—that are attached to very complex and/or lengthy logic. As soon as you try to re-add the flow instance to the procedure, PowerApps simply removes all the code in that procedure, and often—but seemingly randomly—all the code in every property of that object.
Uff, I was hopeing to find a straight forward solution, thinking I had messed up and done something wrong. I am happy to see that I did correctly, but unhappy to see that it is an issue that may reappear in the future randomly. In my case, I cannot rewrite the code because it is just way too long. And I cannot export and import as new, as it is some columns in sharepoint that contain a link with the JSON code that calls for this flow, meaning that I will need to update the code in over 50 sites? (I haven't found yet how to create a column automatically with this JSON code every time a new site is created...)
Changing the owner of the flow worked, so thanks a million.
Changing the connection on a connector and trying to run a test from within editing the flow is what causes the bug.
I've tested this multiple times. Every time results in the flow corrupting and having to be restored from a backup. The restore (of importing to update the corrupted flow) and picking the connections you want to use is what is fixing it once more. It's like it can't handle having two different connections for the same service, followed by immediately testing with a previous run - it's at that "test with previous run" step that doesn't seem to "initialize" the permission step where you'd click "Continue" before you get the "Run Flow" option.
So, what I've done for the last year to prevent the bug from happening:
1. If I ever change connections, I do so by exporting and importing - so that during import I can select the correct connections.
2. Then I can safely test the flow with a previous run.
I also back up my flows by exporting before ANY changes, EVER.
I agree though that all these extra steps are silly because Microsoft should just fix this unintended bug. Hopefully, this helps it get solved somehow.
Learn how to create your own user groups today!
Check out the new Power Platform Community Connections gallery!
Join us, in-person, December 7–9 in Las Vegas, for the largest gathering of the Microsoft community in the world.