Get the Global ID value of a feature from inbox

2168
8
08-04-2020 06:24 AM
JimW
by
Occasional Contributor II

My user needs to be able to take a picture of the mark outs he made to a repair location.  This repair location location is the parent layer in a one to many relationship and is captured by a different individual at an earlier date.  However, because my user is editing existing data via the inbox, they cannot add a second picture to the repair location feature.  I thought I could create a hyperlink in my form that would launch Collector to allow the inspector to take a photo and attach it to the repair location feature service.  I can launch Collector using the URL parameters and open the correct map with no issues but the inspector has to select the point and go into edit mode before taking the picture (not that big a deal).  I would really like to be able to launch Collector and have the map open in edit mode for the repair location so all the user has to do is take the picture and save.  In order to do this, I need to provide the featureID parameter which is the global id value of the feature. I successfully hard-coded the hyperlink with a known globalid value and it works but what I really need is to get the globalid value of the inbox feature being edited.  Is it possible to return the global id value of a feature in Survey123?  Thanks.

Tags (2)
8 Replies
JamesTedrick
Esri Esteemed Contributor

Hi Jim,

I'd encourage you to take a look at the new URL parameters that have been added with 3.10 - Integrate with other apps—ArcGIS Survey123 | Documentation .  This will allow you to construct a link to edit a specific record from Collector, using either globalId, objectID, or another unique field.

0 Kudos
JimW
by
Occasional Contributor II

Thanks for the reply.  I am not sure if I described what I am trying to do correctly?  I want to go from Survey123 and open a record in Collector.  I want to get the globalid value of the feature being edited via the inbox in Survey123 so I can construct a URL, in a note, that will open Collector in update mode, for that same inbox feature so my end user only has to take a picture in Collector and submit.  The Collector help for initiating an update indicates I need the parameter featureID, which would be the globalid of my inbox feature, but I don't see how I can get the globalid value inside of Survey123 and it doesn't appear that I can pass another unique ID field to Collector.  

BenSmith6
New Contributor III

I'm having exactly the same issue and cannot find an answer anywhere

0 Kudos
DougBrowning
MVP Esteemed Contributor

I would do the other way around.  Have the parent in Collector then launch the 123 form passing the key to it.  That way the second visit is a new record that is related to the parent and not just adding a repeat.  Having a bunch of people edit the same form is dangerous plus you lose the location, date, editor tracking, etc of each visit.  I do it this way a lot and it works great.  I do it this way   https://community.esri.com/thread/221263-mapping-with-survey123-within-a-polygon-or-admin-unit 

I also do not use globalids for keys for the reasons here Related Tables for Offline Data Collection 

Hope that helps.

0 Kudos
BenSmith6
New Contributor III

I would love to do it that way around but I need to store data without a geometry, then go back and add the geometry later. The only way I can see of doing this is Survey123 to collector.

I also can't capture the geometry in Survey123 because it only supports WGS84 and that will cause errors in the areas, amd the project is billed based on the area

0 Kudos
DougBrowning
MVP Esteemed Contributor

Are you saying that the area() function in 123 does not compensate for that?  A small test seemed to work but so hard to tell without a set feature.

It would be nice to know if area() does not actually work right.

Thanks

0 Kudos
BenSmith6
New Contributor III

area() works but WGS84 isn't accurate. So if I captured the feature in Survey123, I'd have to reproject everything, whereas just grabbing the GlobalID of the parent feature and sending it out to Collector would avoid all of that

0 Kudos
DougBrowning
MVP Esteemed Contributor

What I am saying is If 123 only supports WGS84.  And area() does not somehow compensate for it being WGS84.  Then that means area() is always wrong. 

Why would the 123 team put in a function they know never works correctly?

Hopefully the team can weigh in here cause this seems weird.  Google Earth and such all do something to make it work.

thanks

0 Kudos