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