Spring '18 - Duplicate Field Error on SFM Load

[nick_sauer]

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.

[sonia_genesse]

Hi Anita D'Souza​,

Thank you for this update!!

I'm pleased to here we are closing in on a solution. Does the Eng Team have an estimated date in mind at this time for the fix?

Thanks

Sonia

[Anita_Dsouza]

Hi Sonia Genesse​ - The current ETA on this fix is around ~2-3 weeks.

Thanks,

Anita

[sonia_genesse]

Hi Anita D'Souza​

Great, thank you!! Do we know if this will be part of Predix 18.2 18.3?

~Sonia~

[mmajerus6]

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​

[Anita_Dsouza]

Michael Majerus​ - Can you confirm if you are on 18.30000.10 build?

[mmajerus6]

Hello Anita D'Souza​. We are on 18.3.00006. Do you think moving up to build ....10 would solve our issue in any way?

[Anita_Dsouza]

Yes Sonia- We have a patch 18.20000.33 for Spr'18 available as well.

[smusku]

Hi Anita D'Souza​

The fix provided in 18.20000.33 is not working in our org. We are still getting the same error. Provided more details through the support case.

Thanks,

Sandeep

[russjaco]

Hi

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.

Thanks

Russ

[sonia_genesse]

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.

Thanks,

Sonia

[sonia_genesse]

Hi,

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.

Thanks!

Sonia

[Anita_Dsouza]

Thanks for the update, Sandeep Reddy Musku​ and Sonia Genesse​!

Rajesh Rao​ Santosh Nadagowda​ - Could you please look into this asap? Thanks in advance!!

[mmajerus6]

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.

Omar Rodriguez​ Anita D'Souza​ Lisa Mercer​ Brittany Taylor​ bio-rad​ sfm_error​

[mmajerus6]

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​

[sonia_genesse]

Michael Majerus​, Richard Lewis​,  Sandeep Reddy Musku​,

This seems to be a SF date parsing issue, here's a good post:

exception - JSON: Cannot deserialize instance of date from VALUE_STRING - Salesforce Stack Exchange

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.

Thanks

Sonia

[mmajerus6]

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.

[sonia_genesse]

Michael Majerus​,

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.

Thanks

Sonia

[richard_lewis]

No sign of it yet.

Regards

Richard

[richard_lewis]

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.

Regards, Richard

[sonia_genesse]

Richard Lewis​.

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.

Thanks,

Sonia

[omarrodriguez]

https://userdocs.servicemax.com/ServiceMaxHelp/183/en_us/svmxhlp.htm#security.htm

Enforcement of CRUD and FLS in ServiceMax 18.3

&

Upgrade Considerations

GE Digital recommends that you take the following points in to consideration before upgrading to this release:

1. It is recommended that you upgrade to 18.3 first in a sandbox, with GBL031 set to TRUE for the active global ServiceMax configuration profile. Then execute a complete end-to-end testing of all the business processes, covering both configuration and delivery screens.
2. If you encounter any issues, you can change the GBL031 value to FALSE to confirm that it is because of the security enhancements. Then update the CRUD and FLS settings for the affected Salesforce profiles, to provide access to the required objects and fields. Update the setting to TRUE again and re-execute the failed tests.
3. If GBL031 is already set to FALSE in your existing ServiceMax org, upgrade to 18.3 will not change the setting value. However, GE Digital strongly recommends performing the steps 1 and 2 specified above to verify the CRUD and FLS permissions as soon as possible, and use the FALSE setting only as a temporary measure until permission issues are resolved.

[mmajerus6]

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.

Anita D'Souza​ Lisa Mercer​ Brittany Taylor​ bio-rad​  field level security​  predix servicemax fsm 18.3​ 18.3​

[Anita_Dsouza]

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.

Lisa Mercer​ Shivaranjini Gangadharappa​

[mmajerus6]

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.

Lisa Mercer​ Brittany Taylor​ Omar Rodriguez​ bio-rad​ fls​ permissions​

[Anita_Dsouza]

Thanks for the details, Michael. Could you also provide me the Case# as this sounds like a defect related to FLS and I would like to follow-up with Engg.? Thanks!!

Shivaranjini Gangadharappa​ Lisa Mercer - FYI.

[mmajerus6]

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​

[omarrodriguez]

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 ).