Hi all - has anyone else seen error on entry of all SFMs:
We are not using this field on any SFMs, and cannot tell why the message would be given.
Anita D'Souza. Is the first fix for this issue already in 18.3? We just upgraded our sandbox to 18.3 over the weekend (Friday), and we are seeing the following issue with our 'Accept' SFM which is impacting our training for an upcoming ServiceMax roll-out in Brazil.
Error message details:
bio-rad Lisa Mercer
Just to confirm, this caused us an issue, when we upgrade to 18.2, everything was fine in Summer 17, thankfully it was a field name to could update easily, but it did take some time to change everything in our Talend middle-ware.
Hello All and Richard Lewis
Engineering has provided the first part of a 2 stage solution to defect 43715.
An interim build ( 18.20000.33 ) was released on Friday to resolve the first issue. This is the issue you are facing on the SFM Delivery side. It will prevent the Duplicate API error that is currently occurring.
The second part of the fix to the Designer is more complex and is not yet resolved. Prior to 18.2, Custom Fields with Duplicate API Names were not displayed on the Designer. This prevented customers from selecting custom field names which would have been duplicate API names. In 18.2 and onwards, due to a change in the Salesforce API behavior, Custom Fields with Duplicate API Names where made available in the Designer.
The Designer fix will prevent the Custom Fields with Duplicate API names from being displayed. The SMAX recommendation is that you do not try to use Custom Fields with Duplicate API Names in Designer.
The fix for 18.20000.33 has been applied to one of my Sandboxes, and while it did fix some of my SFM's 2 of them are still receiving the Dup error.
For one of them the error does look a bit different, and now references a Delivery Controller error as well, I hadn't seen this previously.
Sandeep Reddy Musku also mentioned above that this error message persists as well after the fix.
We just applied the 18.3 patch this week and are now seeing the same error which is preventing us from saving the record. I believe it's related to the user's locale and how the SFM is treating the date time field. Editing on the SFDC page layout returns no error, so this is definitely an SFM error.
Sonia Genesse Richard Lewis Sandeep Reddy Musku Have any of you seen this new error that we are getting post patch installation? "Cannot deserialize the instance of Date from Value string"? It's related to permissions during the API call for the SFM load, but has never affected us before for the same configuration and user until we applied the patch. SMax engineering is working on identifying the root cause for the error, but I wanted to see if anyone else has seen this during post-patch testing.
bio-rad permissions 18.3 patch
This seems to be a SF date parsing issue, here's a good post:
Interestingly enough, I also have one SFM with an "SFM DeliverController" issue, though the error is "List Index Out of Bounds"... though different errors, they're still both referencing the Controller as the main source.
I wonder if this "fix" has actually unearthed some specific issues for some of us individually .....and in different areas.
Thank you Sonia Genesse. I think you may be right about the Controller change. SMax Engineering identified the backend field causing the issue, but so far I haven't been able to find the field in our org, much less being referenced within the SFM which is throwing the error. Making the same update on the SFDC page layout does not return the error as if I do the update in the SFM. Please let us know if you have any additional issues so that we can track these together as related to the version and patch.
Something tells me this may well be something in their code when used in the Controller and how its interpreting that back-end field. Let me know when/if you find out more details about this.
I will certainly keep you posted with any additional information and/or issues I come across as well.
Support was going to pull some log files regarding the Controller issue on my end, waiting to hear back on those findings.
No sign of it yet.
We have just applied 18.20000.34 to our sandbox and it fixed the duplicate error we were having when a user was trying to open an SFM from a wizard.
Just upgraded to 18.20000.34 in my Sandbox on Friday as well, and this was to resolve affected SFM type = "Source Object to create new header and child records". Which resolved the one SFM that I continued to have issues with in 18.20000.33, which was of this type.
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
Hello Michael Majerus,
Good to say hi again.
I have just saw this post now. I will be following up with you from case 00074621. (Dont forget to send me an email next time or responding in a closed case for a faster response ).