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.