Enterprise WSDL maps objects to different types in different organizations

Question

I have two organizations, one for development and another for production/sandbox.

When I generate an enterprise WSDL from production/sandbox I have some lookup relationships mapped as Name. When I generate it from development I get the same relations mapped as sObject.

I would like to know why this is happening and if there is a way to have the same relationships mapped as Name in both organizations.

Examples:

This is the WSDL generated in the development organization:

<complexType name="Lead">
    <complexContent>
        <extension base="ens:sObject">
            <sequence>
                <element name="AcceptedEventRelations" nillable="true" minOccurs="0" type="tns:QueryResult"/>
                <element name="ActivityHistories" nillable="true" minOccurs="0" type="tns:QueryResult"/>
                <element name="Address" nillable="true" minOccurs="0" type="tns:address"/>
                ...
                <element name="Owner" nillable="true" minOccurs="0" type="ens:sObject"/>
                <element name="OwnerId" nillable="true" minOccurs="0" type="tns:ID"/>
                <element name="Phone" nillable="true" minOccurs="0" type="xsd:string"/>
                ...
            </sequence>
        </extension>
    </complexContent>
</complexType>

You can notice that "Owner" is mapped as sObject.

Now the same Lead object from production:

<complexType name="Lead">
    <complexContent>
        <extension base="ens:sObject">
            <sequence>
                <element name="AcceptedEventRelations" nillable="true" minOccurs="0" type="tns:QueryResult"/>
                <element name="ActivityHistories" nillable="true" minOccurs="0" type="tns:QueryResult"/>
                <element name="Address" nillable="true" minOccurs="0" type="tns:address"/>
                ...
                <element name="Owner" nillable="true" minOccurs="0" type="ens:Name"/>
                <element name="OwnerId" nillable="true" minOccurs="0" type="tns:ID"/>
                <element name="Partner_Company__c" nillable="true" minOccurs="0" type="xsd:string"/>
                ...
            </sequence>
        </extension>
    </complexContent>
</complexType>

You can see that now "Owner" is mapped as Name.

Both were created using the same API version:

<soap:address location="https://login.salesforce.com/services/Soap/c/33.0/0DFi0000000CjGX"/>
<soap:address location="https://login.salesforce.com/services/Soap/c/33.0/0DFE0000000TYR9"/>

And I am creating both WSDLs as enterprise WSDLs.

Update: My developer edition is in na15, my Sandbox is in na15. My Sandbox is in cs23.

The links I sent before was comparing development to production. Now the correct ones. The first if from development and the second from Sandbox.

<soap:address location="https://login.salesforce.com/services/Soap/c/33.0/0DFi0000000CjGX"/>
<soap:address location="https://test.salesforce.com/services/Soap/c/34.0/0DF180000004CK6"/>

Development still has Lead Owner as ens:sObject and Sandbox has it as ens:Name.

Answer 1

I tested in a few orgs, and I also see different behavior, but doesn't seem to be API related...

With a sandbox on Summer 15 (34.0) and I get back name for Lead:

I also have an Org on NA1, so that is now on 34.0 and that has Name as the type

When I do the same thing in my pre-release Org (so also on 34.0) I get the sObject as the type...

So maybe a Dev vs Prod/Sandbox thing? Re Keith C's comment, I am wondering if there is something enabled in Dev Orgs that requires/causes Owner on Lead to be a Type: sObject? I tried enabling Dupe Rules in NA1, but that didn't cause it to change...

Answer 2

UPDATE: This has been checked against other Summer 15 orgs. It was found to not be related to the Summer 15 release.

I'll leave this answer here for reference.

---

For the links you provided:

https://test.salesforce.com/services/Soap/c/34.0/0DF180000004CK6

That is using API version 34.0, which will be the Summer 15 release.

https://login.salesforce.com/services/Soap/c/33.0/0DFi0000000CjGX

That is using API version 33.0, which will be the Spring 14 release.

It is likely that the behaviour has changed in the Summer 15 release. Unfortunately I don't have easy access to a Summer 15 org to confirm this yet.