I have recently created a backflow preventer collection and inspections map for collector and am using a related table to store my inspections data in. I created a relationship class based on the backflowID with a one-to-many relationship so I can store multiple inspections for the same backflow and an RC based on GlobalID also with a one-to-many. The issue that we're having is that when adding a new inspection in the related table, the backflowID doesn't immediately populate from the point data so the field crew has to input the ID themselves. I had a hydrant survey in survey123 in the past do this through a URL selection in the configured pop-up that brought over the ID of the field into the survey. Is this functionality capable in collector's activity tables? Anybody have the solution?
@Anonymous User It sounds like you have a single feature layer (backflow preventer) and related inspection table, with a 1:M relationship class defined between them. Is the backflowID field specified as the primary key in the relationship with the inspection table? If so, the backflowID should be populated in the foreign key field in the inspection table when a new inspection is created. If you are using a globalID to GUID relationship the backflowID will not be transferred to the new inspection record.
Thank you, turns out I just had to republish it with only the Backflow ID RC. I didn't realize I hadn't taken away the GlobalID RC when I had last published it. I appreciate your help however!
I found this also it will only populate if you have one relate. It will not populate a second related field. I wish it would bring over any field names that matched actually. I do a lookup back to the parent with Arcade for now but then it is not a real field. Attribute rules may help me when they come out.