This isn't a question, but during my creation of this hydrant meter solution I found there wasn't a lot of helpful documentation on REST APIs through power automate using addFeature, updateFeature, and update Geometry and even querying features. I want to explain why things are the way they are because I had to piece all of this from various sources and even just plug and chug to figure all of this out.
This will go through how the field workers do a simple survey to update where the hydrant meter is and how it automatically updates the hydrant meter location on the map on the correct fire hydrant.
{
"type": "object",
"properties": {
"token": {
"type": "string"
},
"expires": {
"type": "integer"
},
"ssl": {
"type": "boolean"
}
}
}
5. The survey told us which Fire hydrant number the hydrant meter is at, so in order to figure out the lat and long of the fire hydrant we have to do another HTTP step. This time the method will be Get since we are just getting the geometry of the queried fire hydrant. The first portion of the URI, “https://services5.arcgis.com/KkzTh8g0dTwlw3DH/ArcGIS/rest/services/Fire_Hydrants/FeatureServer/0” is the first part of the feature service url. The “query?where= “ is indicating you want to query that Feature and immediately after is the field you are searching by. Im not sure why you need the +%3D+ but you do, and then what you are looking for. My flow is searching the fire hydrant number that was in the survey. Note: if you it is a text field you need ‘’ if it is a text field but you don’t need it if it is a number field. &returnGeometry=true since we are trying to locate the lat and long of the fire hydrant and it always needs &f=json&token= and then the token generated from the parse json from the previous steps in the dynamic content.
6.Again we need to parse the query in order to get a useful lat and long that we can use in the dynamic content. First you need to save and test the flow. Then copy the body of the query. Go back into editing the flow and add another parse json. The body of the query HTTP will be in the Content and then press the “generate from sample” button. Paste the body that you copied form the test and press done. It should automatically put the schema needed.
7. Next we query the Hydrant meters to depermine what the objectID is for hydrant meter they submitted the survey for. The last two steps were repeated but with the meter number instead of the fire hydrant.
8. Now to update the hydrant meter feature. This will be another HTTP step, but this method is POST. The URI is again the first part of the feature service url of the feature you are updating with /updateFeatures at the end. Headers will again be “Content-Type” and “application/x-www-form-urlencoded”, and the Body will always start with f=json&token={the token}&rollbackOnFailure=true&features={. Since we are updating the geometry is being updated we start with "geometry":{geometry dynamic content from the fire hydrants},
"spatialReference":{"wkid":102100},
NOTE: if you are not wanting to change the geometry you can skip straight to the “attributes”:
the features will only be able to update by using the objectID, just make sure that is it exactly how the field is named. Additonally you only need the fields you will be changing. The rest of the field will stay the same. Again if the field is a text field you need a ‘’ around it and if it’s a number field you don’t
it will most likely add an APPY TO EACH once you add some of the dynamic content, just leave it.
9. This wasn’t in this flow but if you wanted to add a feature instead of updating a feature you would do the same thing as number 8 but it would be /addFeatures and you wouldn’t need to put the object ID.
I hope this was clear and helpful for anyone else who is trying to do something similar but is having a hard time finding documentation!!
Solved! Go to Solution.
Very well done Anna, this will be tremendously helpful to our organization and can be applied to other workflows as well!
Very well done Anna, this will be tremendously helpful to our organization and can be applied to other workflows as well!
This has been driving me nuts for week. I could get data out and could not get it back in. I have tried passing a bearer token in the header and got a 'Token Required' error.
I used your syntax on the HTTP POST and it works like a dream. Thank you for finding a solution and writing about it so clearly!
@IsmaelChivite can you add this information to your No-Code workflow automation with ArcGIS Survey123 (Directions Magazine) (esri.com)?
Thank you for posting this. Items 3,4, and 5 helped tremendously in solving my issue with attempting to download .pdfs from a public Survey123 in our flow using HTTP in the "Apply to Each" to download the .pdf attachments.
What was happening was that the token returned using the PortalInfoToken in the HTTP action was returning and empty string for public users (no AGOL permissions) but would work perfectly for someone who was actively logged into our organization when running the survey. The result was that the .pdf would not download. The output of the HTTP indicated "there are no attachments to download". However, the flow would show as "succeeding" in PA. It wasn't until a user told us the .pdfs downloaded didn't work that we found the issue.
Solution - Adding the items in 3-4 and using the "token" output from the "Parse JSON" action in the Apply-To-Each's embedded HTTP action worked (at least after the first 5 tests).
Thanks again.