Only one attribute rule triggers with multiple edits in portal map.

[calebmelies1]

I have five attribute rules on a feature service layer.  Each one is supposed to update a "<field>LastEdit" attribute.  Where I have five fields [JobStatus, WorkOrder, EstCompletionDate, DueDate, Dispatch] and their respective trackers [JobStatusLastEdit, WorkOrderLastEdit, EstCompletionDateLastEdit, DueDateLastEdit, DispatchLastEdit].

Each rule looks like:

if ($originalFeature.JobStatus == $feature.JobStatus){
    return $feature.JobStatusLastEdit
} else {
    return Now()‍‍
}‍‍‍‍‍

When in Pro, I can edit all five fields and save my changes and each respective LastEdit field will be updated.  
When in a Portal map, I edit all five fields and only the last field to be edited gets it's LastEdit field updated (I've tried every combination).

Using Fiddler, I noticed that EACH Portal update sends a REST post for applyEdits individually while Pro sends a REST post for updates all at once.  I can't figure out why the applyEdits Post from Portal map isn't triggering all the rules. Is there something I need to do with versioning or another configuration I missed before deploying the FS?

[calebmelies1]

I was able to resolve this but I still think it should have worked with the first code I posted.  By checking the database after every entry, I figured out that any fields not being edited were getting the wrong value. By switching from $feature.attribute to $originalFeature.attribute I was able to get the desired results.

if ($originalFeature.JobStatus == $feature.JobStatus){
    return $originalFeature.JobStatusLastEdit
} else {
    return Now()
}

[HusseinNasser2]

Here is my guess, your observations are correct, portal web editor sends an applyEdit for every edit you make and unfortunately it is not aware of the server side edits happening on the backend (unlike pro). I think whats happening the lastEdits value are nulls in Portal editor and the backend is taking them as just an other "edit"  overwriting what the attribute rule just wrote. That explains why you only see the last edit.

A fix maybe to prevent editing to lastEdits fields by making them non-editiable (through attribute rule) this way portal editor will avoid writing entries to those fields.

The other way is what you suggested by taking the previous lastEdit value.

Eventually we will teach portal editor to be aware of server edits such as attribute rules and refresh the state in the client with the updated values.