While testing the iPhone Summer 16 app, we have found that some features and functions just do not work unless we add a certain field to the SFM view or edit SFM.
Examples of this are:
SFM Formulas don't work unless the fields they update are on the layout. We would like to set some fields in the background but can't because they have to be shown to the tech
Picklist values don't respect the record type unless the record type ID field is on the layout.
If an sfm mapping is setting a field but its not on the layout, the layout goes blank until the record is synced
Lookup context is only possible if the context field is on the layout
A translation of a pick list value will only work on a service report if the field is included on the view layout for that object and is active for the group profile. If the field is not included on the view layout, it just shows the default translation
It would be great to remove these restrictions as it would make the app more flexible, less frustrating to configure and more streamlined/user friendly to the tech.
What is the underlying problem do you intend to solve with this idea?
Ease of configuration and usability for the tech
How is the problem being addressed today, if at all?
Maybe a section of the page layout we could configure called system fields that adds the fields so they can be used by the app but doesn't display to the user on the device.
Hi all - I believe this is the same request as idea 1403, and would request that you also vote there. There are many fields required for various technical reasons. In the best case (online), these clutter the layout unnecessarily and cause frustration for users. In the worst case (FSA/mobile), these make the SFMs very difficult or impossible to use effectively. It would be very beneficial to be able to set these fields as background/technical only so that the system can access but users do not need to see/edit.
Discovered a new issue today so added another bullet point to the list in the original post:
A translation of a pick list value will only work on a service report if the field is included on the view layout for that object and is active for the group profile. If the field is not included on the view layout, it just shows the default translation
We would like to have some fields display with the correct translation on the service report even if they aren't included on the view layout for the object. I suspect its working this way because the app only downloads the pick list values and translations for fields which are on the view layout.
At Maximize last week, I asked for an list of which SMax functionalities require fields to be on the layout: literals, mapping, filtering, formulas, and/or translations. I believe MunMun Malik and Anita D'Souza took the action item to try find a comprehensive list of rules for each functionality.
Ideally, we would not need these fields on the layout, but until that functionality is in place, our approach is to group these fields in a separate section at the bottom of the layout rather than cluttering the actionable sections of the work order. Currently, the SMax page layout does not remember if we have chosen to collapse a section as it does in Salesforce, so we have trained our users ignore the section.