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

Flexible Required Form Elements Between App and AGO?

KansasDASC

We have a FM deployment and our field staff were wondering if it was possible for the FM app to have a couple required form elements for the fields that need to be filled out in the field, but then when they go back to the office, a selection of the remaining elements are required when editing in the AGO map form.

We want staff to have the flexibility of either filling out only the required field elements or they can fill out more, but then they can fill out the rest of the same form in AGO. Is this kind of workflow possible?

It's been floated that we might need to create a second map and add the same layer to it, build a duplicate form and then we'd have one map for the field, one for the desktop users, but both maps/forms would update the same FL and tables.

Find more posts tagged with

Accepted answers

KansasDASC

Thanks for a thoughtful reply and all good things to consider. I certainly will always err on the side of simplicity as well so I am shooting for easy, straightforward solutions.

After posting this yesterday, I looked into conditional required fields as a possible solution and so far it's better than anything else that has come up. I deploy the full form with, say, five required form elements that the field staff have to complete in the field. Then when they return to the office, there's a "Location" element that when toggled to a value of "In Office" forces other elements to be required that weren't required in the field. There's some Arcade expressions to try out and those would be used for each form element that should be required once in the office.

All comments

KansasDASC

If others are looking for something similar. The Arcade expression I'm using for the conditionally required vs. not-required is:

// For a field that should be required when status is "Complete" or "Final"
if ($feature.Status == "Complete" || $feature.Status == "Final") {
    return true;
} else {
    return false;
}

Referencing a form element called Status with values for Office and Field.

KansasDASC

I tested it through the app on iOS (iPad) and desktop AGO map viewer and both worked as expected. Only difference is maybe the messaging and slight user experiences, but the functionality is there. The code isn't complicated, so maybe if it was a bigger expression with varying dependencies, then it could get tripped up somewhere.

MichaelLohr

That sounds promising. Does it work in all the various ways that people may use the forms, like in the office web browser, mobile device Field Maps, web apps? Sometimes certain functions will give problems from one or more of these possible end user applications. I think I have read somewhere that conditional functions did not work, like maybe in Field Maps, or OK in iOS but not in Android. Good luck. Your reposting update is helpfulto others who maybe haven't tried conditional formatting.

KansasDASC

Thanks for a thoughtful reply and all good things to consider. I certainly will always err on the side of simplicity as well so I am shooting for easy, straightforward solutions.

MichaelLohr

This is my perspective only and others may comment differently. It is certainly wise to look for practical alternatives that don't overly complicate the data collection process and provide additional flexibility. But there is a break-even point where it doesn't make sense to pursue some possible option that has unknown outcome.

If you have a Field Map with both mandatory and non-mandatory fields, the field data collector always has the ability to fill in as many fields as he can. The Map Designer must decide which fields can only be filled in by the on-site person and these become mandatory. Thinking that the same field person will always be the one to populate missing fields during QA can be a mistake, it sometimes (often?) is not the same person. The decision to make certain fields mandatory is critical. Too many and precious field time is wasted. Too few can result in return trips later.

Sometimes a process modification can be done to improve flexibility and still maintain efficiency. This is always a judgement call and sometimes not an easy one. My practice, over the years is to err on the side of simplicity. The suggested alternate of creating a separate online map in which to enter some of the data input may reduce field efficiency as the field staff is changing maps back and forth. And to have to do that when visiting an individual facility, doesn't make sense to me, on the surface. If you can develop a second form to use on the same online map, that might be better than a second map, even if the second map populates to the same geodatabase.

This is where the extra process complexity has to be considered. Is it worth the extra effort and lower efficiency in the field to gain the additional flexibility? Each situation will be different, of course. We have often declined to pursue a request for a new option that to others might seem like an easy thing to do and without any negative effects. The requestors don't always understand how the overall system works, and the tail ends up wagging the dog, so to speak.

Hope this is helpful.

Join the Conversation

Signed in members can post, follow updates, and more. New here? Register a free account.

Quick Links

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