nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

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.

Najděte více příspěvků označených jako

Accepted answers

All comments

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.

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
	}
}

Připojte se ke konverzaci

Přihlášení členové mohou přispívat, sledovat aktualizace a další. Jste tu noví? Zaregistrujte si bezplatný účet.

Rychlé odkazy

Community Help
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.