Hi all - there seems to be some loosely defined checks within the SFM load engine. In this case we had a field with api name of "Group_Email__c" which is similar to "SVMXC__Group_Email__c" of course. It appears that the namespace is not part of whatever check was failed above, so SVMXC was blocking due to belief that these two fields were the same.
In any case, leaving this here in case it helps anyone else.
We have the same issue with several fields across our org. In the SFM, the designer does not distinguish between the (2) fields even though (1) is the OOB SMax field with SVMXC, and the other is a custom field. When this happens the SFM engine gets confused and key SFM features do not work correctly.
Thanks Michael for the information - quite strange really to apparently not include the SVMXC__ bit in the duplicate check. Unfortunately it sounds like your fix will be more onerous than ours as we only have one 'duplicate' field to this point!
I inherited an org with lots of opportunities for optimization... Copying Anita to this thread as the new SFM designer may in-fact account for the SVMXC prefix. That would be a welcomed improvement.
We are running into this same duplicate field issue with the SVMX_Entitlement_Type__c field. There is an OOB field on Case called Entitlement_Type__c. This happens when you perform an action on a Case FSM.
Since we cannot change the SVMX_Entitlement_Type__c as it's part of your managed package and we shouldn't change the standard Salesforce field Entitlement_Type__c can you please get back to us on what we need to do to fix this?
Where are we with this one? We just did a deployment to our full sandbox for UAT and there is now a conflict with field Service_Maintenance_Contract__c (vs. SVMXC__ namespace version of same) that is coming up. This did not appear with same SFMs, etc. in our development sandbox, and now our timeline is going to be negatively impacted as multiple classes would have to be redone.
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.
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.!!
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.