Field Maps Update Domain Status Loses Attribute Information

[JoshConrad1]

Hello:

I have developed a web map that our field crews are using to track work orders through Field Maps. The web map has a hosted feature service published from ArcMap.

I have the map symbolized by a domain field drop down, along with grouped fields and conditional visibilities based off of the status chosen.

The field crews have been able to successfully fill out the form, however when they change the domain back to the status that has the conditional visibility expression attached to, the attribute information gets completely cleared out.

Please help.

[Anonymous User]

Hi @JoshConrad1 this is intentional behavior. If a field becomes hidden, it's values are cleared. The reason for this is to prevent "invalid" data from being persisted (primarily when creating new features). If you are using some kind of status field, where different sections of the form are visible based on the status field, you'll need to use a more complex Arcade expression like:

$feature.status == "value1" || $feature.status == "value2"

This would show the field/group for either of the two statuses.

Can you describe your data model a bit more? Are the workers updating existing features, adding related records, or creating new features?

[JoshConrad1]

@Anonymous User 

Thank you very much for your quick response.

Our data model consists of crew members updating existing features and creating new ones. No related records. They will create the new point, and the status will be set to scheduled. It will remain scheduled until the work is scheduled to start, then they will update that point to active, and so on throughout the work order until it is complete.

Our form consists of 15 or so fields, and 3 of those fields are generic base data: work order #, location, and work type. Those are required regardless of any status or conditional visibility.

The rest of the form is conditionally visible based on the status field entry (scheduled, active, backfilled, etc.). If the work order is set to scheduled, then the rest of the form is not visible (it is designed to keep it simple for our field crews - only see the fields they need to when they need to). Not only this, but we want certain fields to be required, and without this conditional visibility, they would not be able to complete the form due to the fact that they will not know certain entries (excavation size for example) until the work order is set to active. Additionally, when the crews update the work order to anything but scheduled, they see the rest of the form. Those fields are grouped, and the group has a conditional visibility:

$feature["LAYER_NAME"] != "SCHEDULED"

Everything is working as it should, however my only concern is if our workers decide to change the status back to scheduled (logically, they should never have to do this but I am trying to eliminate all possibilities of error) they will lose all of the important information they filled out during the work order process.

Knowing that it is an intentional behavior, and assuming my conditional visibility expression is correct, then it seems like my plan of attack would to be informing them of the lost data possibility.

Am I understanding this correctly?

Thank you again!

[Anonymous User]

Yes, I think you understand it correctly.

[JoshConrad1]

@Anonymous User 

Is there an expression or functionality that I can build into my form such that once the status is set to anything but "SCHEDULED", the field crews will be unable to change it back to that status?

Thank you again for this insight.

[Anonymous User]

@JoshConrad1there isn't anything that can do this right now. Potentially this could be accomplished with Attribute rules or Contingent values in the future.

[JoshConrad1 · Accepted solution]

@Anonymous User 

We are using the form to track work orders based off a status field, and we want a conditional visibility expression to make an associated date field appear based off the status as it progresses, all while making sure that we never lose data along with making the date fields required.

Knowing our workflows, I am going to configure the conditional visibilities on the date fields in a semi-pseudo descending order (very similar to your solution in your first reply):

If we have the following statuses: STATUS 1, STATUS 2, STATUS 3,  then STATUS 1 is the first step of the work. The field crews cannot get to the remaining statuses because those are later in the work order process. So logically, when the field crews are on STATUS 3, there is no way they will need to return to STATUS 1.

STATUS 1 DATE FIELD CONDITIONAL VISIBILITY =

$feature["LAYER_NAME"] == "STATUS 1" | | $feature["LAYER_NAME"] == "STATUS 2" | | $feature["LAYER_NAME"] == "STATUS 3" 

STATUS 2 DATE FIELD CONDITIONAL VISIBILITY =

$feature["LAYER_NAME"] == "STATUS 2" | | $feature["LAYER_NAME"] == "STATUS 3"

STATUS 3 DATE FIELD CONDITIONAL VISIBILITY =

$feature["LAYER_NAME"] == "STATUS 3" 

Configuring the conditional visibilities this way allows the date field for STATUS 1 to remain as the work flow progresses throughout the project. Then when the work order gets to STATUS 3, the date of STATUS 1 and 2 will remain.

[JanetSilb_Spike]

Hello @JoshConrad1 & @Anonymous User .  I think I have run into a similar challenge. My client is using Field Maps to monitor the condition of trees on a restored site every spring & fall for 5 years through a contract with the city. So far they have used the form I configured this past spring (May) and fall (Aug) 2022. However we just noticed that the Spring22 Condition field is now empty and the Completed field set back to "No" for those features monitored in Aug.  I did set up the form to have fields grouped by season/year (e.g. Spring 2022), and then set conditional visibility for the group so that if the autopopulated Monitoring Date falls outside of the designated season date range, then that group is not visible.  

Fortunately I have the Spring 22 collected data backed up so I can repopulate the fields. Can you please advise me on how to create the more complex Arcade expression to preserve each season's data going forward?

[JanetSilb_Spike]

Actually @Anonymous User , it is not straightforward because not all data cleared, nor does it clear if I edit the fields now. Would you be willing to do a brief screen share call with me?  --Janet

[JoshConrad1]

@JanetSilb_Spike 

Were you able to reach a solution for your data loss issues?

Our original problems stemmed from domain changes in a "status" field for a work order layer (Status domains = SCHEDULED, IN PROGRESS, CLOSED) that were included in conditional visibilities. If our field crews were to need to change the status throughout the progress of the work order, the entire form that was not associated with the conditional visibility would be completely empty.

Our solution was to configure the conditional visibilities for each of the statuses with descending order:

STATUS 1 DATE FIELD CONDITIONAL VISIBILITY =

$feature["LAYER_NAME"] == "STATUS 1" | | $feature["LAYER_NAME"] == "STATUS 2" | | $feature["LAYER_NAME"] == "STATUS 3" 

STATUS 2 DATE FIELD CONDITIONAL VISIBILITY =

$feature["LAYER_NAME"] == "STATUS 2" | | $feature["LAYER_NAME"] == "STATUS 3"

STATUS 3 DATE FIELD CONDITIONAL VISIBILITY =

$feature["LAYER_NAME"] == "STATUS 3" 

You mentioned that your form was not completely cleared out, and that various records were reverted back to "NO". Is this a default value for the inspection form? If you are still experiencing data loss issues, I would consider starting by removing your grouping and adding a new field with a domain "SPRING" and "FALL". then having conditional visibilities on the data based off of these entries.

How do you have your conditional visibilities configured? We had to create the descending theory because we needed the information for status 1 to remain throughout the duration of the job. So Status 1 needed to be visible for status 2 and 3/Status 2 needed to be visible for only 2 and 3/ and status 3 needed to be visible only when 3 was entered.

Hope this helps and let me know how else I can help.