My recommendation would be for each of you to log a case. That way the magnitude of the issue can be tracked internally. I have also made some internal inqueries and waiting to hear back.
I do also notice that after I receive one of these SFM errors, that I'm no longer able to open that specific SFM again in order to replicate it. Instead I receive this: "Processing Page Layout and setting" message and the page never loads.
I was able to replicate this SFM error on a different SFM and then when I attempt to recreate it I receive the error below again.
Is anyone else finding this to be the case as well? While I do have this version loaded into my PARTIAL SBOX only at this time I'm not certain if this behavior would be seen in a FULL SBOX or PROD Org.
Even if fields aren't mapped this issue is occurring, this is only a problem when on an Object exists for two similar fields, one OOTB 'SVMXC__' field and one custom field as shown below as an example, and as previously noted above in this post by others:
In my case I have multiple Objects with this situation.
I have also entered a Support Case and referenced this Community post.
Hi all, We experienced this what feels like it must have been a few years ago.
Feels like an idea which we can all vote on may help ServiceMax focus on this as they clearly aren't treating it as a defect in their package which I view it as. Please vote.
Just a quick update.
For the short term this is what is being proposed, though they're still looking at other options and involving SF in the conversations.
While the workaround below may work for some, I have integrations setup using Dell Boomi for which SF is integrated to two other applications. This would cause more significant updating on my end, if I where to modify the API names only in SF it wouldn't be as much as a pain.
Change the custom field API name to different from installed package custom field API name
More details on this here: https://success.salesforce.com/answers?id=90630000000DNMeAAO
Proceed with Caution: https://help.salesforce.com/articleView?id=000247975&type=1
Sounds like it was never a "best practice" to create a custom field/label with an already existing SVMXC field. Though in my case, a SMAX Developer created these before my time here.
I believe Richard Lewis you are correct when you recall this from years past.
Thanks for the update Sonia Genesse
I am not sure I understand the challenge here. The fields aren't the same. They have different API names so the ServiceMax matching logic should be considering the full API name and not just what is after the prefix. I am sure Salesforce requires API names to be unique within an object and does the match check correctly.
We will await further feedback from support but it would be good to have some more information to understand why this is such a problem to change.
If you have a list of the ServiceMax best practices to use when developing to avoid hitting problems like this please can you share it with us. Or if you don't, could you see if support can provide one if they are quoting best practice to you?
Hi Richard Lewis
What this means changing the API Name "behind the scenes" as the logic doesn't take into account the NAME SPACE, which in this case is the 'SVMXC' prefix thereby making the fields a "Duplicate". Therefor, to any code these fields "are the same", to you and I they are not. Your users would continue to see the Field Label on their Page Layouts, Reports etc...
As for the "best practices" I don't have anything like that to date, this is simply something that was said to me from Support. This is more of a general statement as far as I'm concerned. I have had to make similar changes to API Names in the past for a number of reasons, some while in PROD and others while still n development. Therefor I do feel this to be loosely defined in my opinion.
Some comments from the SFDC Stack Exchange:
You can find many other posts on this topic as well.
Discussions between SMAX and SFDC are still ongoing regarding this topic is what I was told.
Regarding the error of duplicate fields in 18.2 , there is a defect with engineering. Defect #043715.
I have seen this workarounds :
1) The recommended solution from salesforce is to change the API name of the custom field. So, it would not conflict with managed field API name. Below is the knowledge article which recommends this.
2) Also hiding access to the field might work.
Just a reference I wanted to share, if one of this two works for an affected org, good for now.