Thanks for your update.
While updating the API Name might not be a big deal for some folks, this is greatly impactful for me. Reason being, I have SF/SMAX integrated with our ERP system using Dell Boomi. You are talking several hours of work for each object effected.
Hoping there's another solution, keep us posted!
We also found a very similar issue in the ServiceMax Winter17 iPhone Mobile app (and probably multiple other versions too):
The ServiceMax Priority field is what is used in the mobile app to be able to colour code events on the calendar view.
We were finding that in the app, no matter what we did, we could not get the colour coding to work. It always displayed the default colour and behaved as if the event was related to a custom object (so when clicking it you get the event view), rather than a Work Order (where you click it you should go straight into the WO summary view).
Case 70472 was raised with ServiceMax support and after about 2 months, we were told the issue was caused because the mobile app doesn't read the namespace when getting the fields, so it was getting our custom field instead of the ServiceMax priority field and therefore causing the colour coding to break.
The recommended solution was to change the API name of our custom field Priority__c. We changed it to Priority2__c and immediately it started to work. But there was a lot of pain involved in changing the field api name in all classes, triggers etc. that referenced it!!
Fully support the idea that the ServiceMax package should work with the SVMXC namespace and include this whenever reading or checking fields.
Here is the latest feedback from my open Support Case today.
Engineering has advised they are unit testing a possible fix and verifying the impacted areas. I'll keep you posted with further updates I receive.
I asked for an update today, and below is what I received:
"Engineering is in the process of verifying the impacted areas. We are expecting an update tomorrow so I'll be sure to share that with you once I receive it".
Thanks Sonia Genesse, we have a case in for this as well and it looks like it is linked to the same defect with engineering so hopefully we should get the same updates going forward. We hypothesise that there is a code change in smax 18.2 that refers to the Product field on a Case and is now causing us issues with the duplication problem but wasn’t before.
Hi Richard Lewis
Yes, upgrading to 18.2 is what introduced this issue for me as well, that wasn't previously a problem.
The meeting about this is every Friday, my Support person is OOO today, so I likely will not hear back until early next week. She did call me on Wednesday and stated the fix they have been working on may be a viable solution, though they were still working on testing impacted areas. This keeps me hopeful.!!
The double underscores at each end are ignored when it checks for dupes. I’ve experienced this I’m my orgs.
I want to share this references as well:
Because is a NO FIX issue, there is an idea in the SFDC Idea Exchange as well: https://success.salesforce.com/ideaView?id=08730000000E0bnAAC
Other similar Salesforce Known Issues for your reference:
ServiceMax Engineering, Developers and Arquitects are working on the solution and testing the fix for the customers that cant use the actual workaround. Thanks all for your patience.
Thank you for the update.
I did vote this up in the SF Idea, though it has been open for 2 yrs now and is under the point threshold, like most SF Ideas go to die!
This is preventing me from upgrading and now I'm not in the active Support window, which is problematic. Tried to upgrade in the Spring ahead of another internal upgrade to an integrated system, but ran out of time due to other issues encountered during testing.
Just wanted to provide an update on this issue and why you are running into this. We recently updated our Apex class API version from 22 to 39 to keep current with SFDC API versions. With the new API, when managed package is querying for fields of a given object, the namespace prefix is applied to all fields on the managed object which is now leading to duplicate API error. We have had several conversations with SFDC on this regard and their recommendation is not have 2 fields with same name(ignoring the namespace). Here is the knowledge article that we where directed to: https://help.salesforce.com/articleView?id=000247260&type=1
Since this approach of changing field API might not be ideal due to field dependency in other areas of the platform such as integrations, custom code, workflow etc, we are changing the query behavior to work similar to AUT17 where such conflicts are resolved by giving preference to managed package field. The engg. team is currently doing QA on this fix and a patch fix will be provided shortly.
Thank you for your patience.