GE Digital recommends that you take the following points in to consideration before upgrading to this release:
Hello Omar Rodriguez. Thank you for posting this.
I wanted to get further clarity about this new setting. In Salesforce, if the user does not have View access to a field, it doesn't show up on the SFDC page layout. Likewise, the field is also not visible on the SFM page layout. That is consistent based on the field's FLS.
The difference comes during an edit to the record. In Salesforce, the user can use the native 'Edit' button on the Salesforce page layout to edit a different field on a Work Order without receiving an error.
However, with the 18.3 ServiceMax Update, we receive an error when trying to edit the same Work Order record using an SFM. This seems strange, as the user is not trying to edit the field for which they do not have access. They are editing a different field and trying to save the SFM. Is this intended behavior?
I believe the purpose of this new feature is to respect the Salesforce permissions in ServiceMax, but this seems to be a big difference in how record Edits are managed in relation to FLS. This means that from now on, any profile which accesses an SFM needs at least View access to every single field being referenced in that SFM even though they are not editing that field. The strategy of selectively hiding fields on the SFM page layouts for some profiles using FLS would not be possible anymore and will take a good deal of analysis and rework to clean up across all SFMs.
To note: our SFM page layouts are Global, but regionally, some fields on the SFM page layouts are strategically made not visible using FLS for the region's profile. We have done this in lieu of duplicating SFMs regionally.
Hi Michael Majerus - Could you please clarify the setting value for GBL031 when you encounter this error? Also, is there a case# for this so that I can follow-up internally on the current behavior w.r.t FLS?
Just to clarify, issue related to duplicate API on SFM Delivery has been resolved and a patch fix for the same is available for 18.3 and 18.2 versions.
Hello Anita D'Souza. Thanks for looking into this! We initially had GLB031 set to 'True' per the SMax default after the 18.3 upgrade. When this was true, we were experiencing issues with FLS access in the SFM even though the field was not being edited while in the SFM.
It seems that with this SMax setting set to true, if a field is on the SFM page layout, but the user does not have 'View' FLS access, the SFM will open correctly, but the user cannot update any fields in the SFM and save successfully. Per my previous post, this is different behavior than the FLS in SFDC which will allow a user to 'Edit' fields on a Work Order and save successfully.
I think the SFM engine should both respect FLS and allow the same editing access to all fields for which FLS is defined for the user to access. It should not stop the editing of other fields for which the user does have access. This seems to be the behavior that we were seeing when the GLB031 was set to true.
Hello Anita D'Souza. Sorry for the delay, I was out of the office for a few days. The case number that we logged with Support is: 00074042. It's now closed because we disabled the Global Setting, but if this is really a defect and can be resolved, then we would most-likely re-enable it.
Lisa Mercer bio-rad