Inspections Form - updating feature class but adding a new inspection in a repeat

[clt_cabq]

I have a set of inspections where I would like users to update fields for existing locations in a feature class (or add a new feature) but then add a new inspection. The new inspection and related photos would go into a repeat. Can I do this without creating a new location/point for my feature class? My desired workflow would be for the user to click on an existing location, prepopulate property related fields in the s123 form where those values can be updated, and then open an 'inspection details' repeat where the current inspection information, including photos, would get added. I can know I can use a submission URL with parameters to accomplish the the first part of this workflow but feel like that will simply create a new record in Survey123 without simply updating the feature class. 

[ZacharySutherby]

Hello @clt_cabq, 

If you already have the point layer and related table as a feature service in your ArcGIS organization you can create a Survey123 survey based on that existing feature service. 

If you don't have a feature service with the schema you like I would suggest taking a look at the Hydrant Inspection sample available in Survey123 Connect this will show a workflow similar to what you are looking for using fire hydrants as the assets. 

After you have your schema prior to publishing the survey you can enable the Inbox which will allow you to edit existing records in the Survey123 field app and add new repeats on top of the existing geographic locations. 

[clt_cabq]

Thanks for the suggestions, I'll look at the hydrant inspections example. Mostly what you lay out above is largely the workflow I was messing about with, I was hoping there was away to avoid enabling the inbox but there may not be a good way around that. 

[DougBrowning]

If it is just a few fields using the new Field Maps Designer for the parent may be a way to go.  Then they can use the spatial parts of Field Maps to find their way to the locations too.  They can update parent fields using a Field Maps form if they need to then launch 123 with a URL to make the inspection in a repeat.  Works slick in the end.  The 123 form I always leave a geopoint to show me cases where the crew tapped the wrong parent - which happens way more than you would think it does.  Easy to QA since we know where they were standing.  I even added a note warning them when they are far away from the point they tapped on.

Hope that helps.

[clt_cabq]

Thanks Doug, I was considering a workflow that involved using Field Maps to interact with the parent points, even it it is just selecting an existing point or creating a new one, then launching the form from a hyperlink and loading the form with data. I'm trying to keep this as simple as possible for the field crews so they don't have to deal with multiple applications though. What I'd really love is if there was a way to 'prepopulate' surveys from an existing data layer. 

[DougBrowning]

How do they find these if they dont use field maps?  May be easier in the end.

But Inbox or a pulldata @layer (assuming online) are the only real other ways.  

[clt_cabq]

my form currently uses an address field coupled with a geopoint calculated with a pulldata expression to create a point location. This works well for new locations, but not so great for existing locations (we are shifting from a legacy approach to some inspections that involved spreadsheets, emails, and, paper based lists), so we already have locations to build off of. This is why it would be handy if there was a way to prepopulate surveys based on existing data. 

[DougBrowning]

You can do it  https://community.esri.com/t5/arcgis-survey123-blog/survey123-tricks-of-the-trade-pulldata-quot-laye...  

[clt_cabq]

@ZacharySutherby the hydrants example was pretty instructive, but I'm finding it doesn't feel like it exactly behaves as i anticipate with regard to how it purports to get and display the 'last condition' value. My expectation was that a) if there were no prior inspections it would display the "no inspections logged" text. But, once an inspection is logged, it would display the condition value from the most recent record from the repeat. However, it appears that this shows the 'current' value in the unsubmitted inspection record, rather than the last submitted one. Is there an error in the way that the java script is capturing the data from the last submitted record? This is functionality that I want to employ in my form for a couple of different reasons, so I'd like to pin this aspect down.

Here is the JS script that seems to be the engine behind this approach and I think its lines 4 and 5 that may not be behaving as i am expecting.

function getLastCondition(inspections,maxDate){

	if (inspections.length>0) {
		var maxDateInspections = inspections.filter(item => item.inspection_date === maxDate);
		var countOfInspectionsWithMaxDate = inspections.filter(item => item.inspection_date === maxDate).length;
		var conditionOfMaxDate = maxDateInspections[countOfInspectionsWithMaxDate-1].asset_condition;
		return conditionOfMaxDate
	}
}