How Field Maps deals with conflicts between Task button and Smart Form calculations

Question

Hi team.  I had a workaround for this but since the March Field Maps update, my workaround stopped working.  Now i need another one.

Here's the scenario - You enable tasks, you make a few Layouts, and they follow a sequential order to follow the field workflow from Unassigned to Assigned to Completed (I usually skip In Progress but that is not important right now). Each Layout has conditional visibility driven by the esritask_status field and a few "Edit Field" buttons for common actions.  Some buttons are Automatic, Some are Manual and Automatic but all have one thing in common - they have a calculated expression for the esritask_status field that takes them to the "next Layout" (ie Unassigned goes to Assigned, Assigned goes to Completed, etc).

Thats great - HOWEVER, there is always going to be outlier situations where an Edit Field button is not going to cover what needs to be entered, and so in the Assigned Layout we also have an "Edit" button that opens the trusty old form they've all been using for years.  One of the fields in the form is esritask_status which has a calculated expression of simply 3 to tell the form that when it submits, consider this job "Completed" and take it to the next layout

This has never worked.  If you have a calculated expression in the form then you are stuck with it in your Edit Field buttons as well and if they conflict in any scenario you get stuck in the spinning wheel of nothing happening.  No matter - we have a workaround! We just need to make an overly complex expression in the form like this that does not conflict with anything going on in the buttons:

var edittype = $editcontext.editType
if (edittype == "INSERT") {return 0}
else {
var thisstatus = $originalFeature.esritask_status
var nextstatus = 
decode(thisstatus,
0,1,
1,3,
3,1,
1
)
return nextstatus
}

(in case you were wondering what line 9 is all about, we have "undo" buttons in our Completed Layouts so folks can go back and change what they entered)

And that fine workaround was working fine until 12:30 Tuesday 3rd March NZDT when suddenly 26.1.0 was released, everyone's Field Maps auto-updated, and my phone blew up with angry Field Workers.

So after a bit of testing (on Android and iOS, 25.3.1 and 26.1.0, online and offline) i discovered that the issue everyone was getting was that the correct Layout was taking about a minute to load in 26.1.0 (as opposed to instantly in 25.3.1). (Weird that it was taking the same amount of time offline as online if it's just an issue with a calculated expression but no time to get hung up on that now).

Anway, i need a new workaround.  This is all i have for the moment which is less than ideal.

Righto, lets solve this.  Tasks is awesome but we still need to have a way to have a calculated expressions in Edit Field buttons and calculated expressions in Forms in the same map.

@JeffShaner happy to jump on a call to step through this with you - its a doozy.  I'm totally open Friday 6th your time (Saturday here)

Cheers!

Screenshot_20260305_065828_Field Maps.jpg

Screenshot 2025-04-04 104951.png

Scott_Sambell · Answer

Hi Chris

Thanks for your reply.  I also can't see the point in having the Edit Field button have any connection to the configuration of the form.  We are using Tasks in several projects now and i can't think of a situation where we could make use of that.

This wasn't too much of a problem though because we had the workaround as described above.  Now all our Tasks Field Maps aren't working as they originally did when we deployed them.  The field workers were really happy when we first deployed Tasks but that update really upset things.  Is it possible to release a patch to put things back the way they were so our workaround will work again?

More than happy to jump on a video call to discuss this if you want to have a better look at our work flows.  I'll send you an email to see if we can arrange a time

Cheers, Scott

ChristopherCounsell · Answer

Hi Chris,

Thanks for your reply.

Honestly I can't see the benefits to the current behaviour. From my view if
there are reasons it should be required it should at best be an checkbox on
the button to enforce form validation. Not the default.

If we want to enforce data requirements we can use conditional visibility
on the button or layouts. Constrain the user options to open the form
before a button like 'complete' - and they'll inherently face the form
requirements.

It's a bit of a hidden soft lock at the moment. We had a form configured
and the 'pick up' button didn't work because of it.

Cheers
Chris

ChrisDunn1 · Answer

Hi @Scott_Sambell  (and @ChristopherCounsell ),

We are having active discussions at the moment to determine the best way to update this behavior. If you have additional thoughts feel free to weigh in here, on the idea Chris posted, or send us an e-mail. For example - would it be useful to have the option (via checkbox) to adhere to form calculations and validation on Task edit actions? If the task actions were completely decoupled from the form, there may still be times when you need to enforce data quality rules, such as required fields, date ranges, lengths, etc. Would you want those options available in Tasks in addition to the form?

@Scott_Sambell for the case you are describing, my recommendation would be to simply remove the calculated expression from the form for now. After a user submits their edits via the form, they could still hit the "Finish" button in the task layout to change the status to Completed.

If you have any additional thoughts or questions don't hesitate to reach out, know that we have heard your feedback and that assessing potential changes in this area is a priority for us.

Chris