Hi @BrianG,

If it still works the same as the customisation that was regularly used prior to it becoming baseline then it checks against the contents of the mm_field_sync_view table. If the changed fields are in there then it will create the update in mm_message_out and if not, it does not.

Quote from the customisation design:

For updates however it will collect the relevant fields from the mobile designs (mm_field). This is done by a custom view “mm_field_sync_view” which will returns a distinct list of fields used.

Not sure if these functional only fields would be in mm_field though, or if there would be an issue adding them if not.

Kind regards,

Lee Pinchbeck

@BrianG I had this question too. Thanks for creating a post

Since mm_fields cant be actually used to determine the extract logic, as we use the non mm_fields in client scripts.

So since we mostly define the fields that we require in the sync rules, cant we use them to have this logic? May be when a sync rule is updated, we store the defined fields in a table, and utilize them also in the SQL view “mm_field_sync_view” ?

A suggestion @Lee Pinchbeck 

Thanks @Lee Pinchbeck ,

I’ve accepted your answer, but it does sound like there may be a design gap with the feature.  I will not be using this feature, but I imagine a workaround would be to add hidden fields to a screen for any field that is used in logic for workflow or other reasons.  I would recommend thorough testing for anyone who decides to use this enhancement.