Handling Local Extensions of Managed Objects

[TedHusted]

NUEntityc (for example) is a managed object that we extend in our implementation. In our metadata, we track only the local extensions provided in our implementation, such as new custom fields, validation rules, and so forth. We do not declare items already defined by the base package, such as object and .

• The deltaDeployment Ant Task generates a diff that shows that src/objects/NUEntityc.object changed, and so deltaDeployment adds it as a member of the CustomObject type.
• If we try to deploy NUEntityc.object as a member of the CustomObject type, the metadata API complains because we're missing fields required to deploy a custom object ().
• The expected approach by the API is to declare references to the items we add to the base object, and omit any metadata that is already declared by the base package. So, we declare our CustomFields and ValidationRules on the manifest, but not the CustomObject (since that component is already declared by the managed package).
• We declare our local extensions, like CustomFields and ValidationRules, wrapped in a NUEntityc.object, but we do not declare NUEntityc.object on the manifest.
• If you add a custom field to an Object installed by a managed package, and then pull the metadata for that package (by fullName) from your local org, you can see what the API expects.

If deltaDeployment handled local extensions to managed packages as the API expects, then we could use the task with implementations that extend managed packages.

• Many consulting projects extend managed packages, notably implementations of the Non Profit Success Pack distributed by the Salesforce Foundation.
• Another use case is when a vendor distributes a base package and other packages that extend the base.

Here is an example of adding a local custom field to a managed object.

<CustomObject xmlns="http://soap.sforce.com/2006/04/metadata">
    <enableEnhancedLookup>true</enableEnhancedLookup>
    <fields>
        <fullName>CommunityHubUrl__c</fullName>
        <deprecated>false</deprecated>
        <description>The field contains the URL for this entity&apos;s Community Hub site. The URL listed here may be used elsewhere in Nimble AMS to calculate other URL based fields ... such as the Event Detail URL for Community Hub.</description>
        <externalId>false</externalId>
        <inlineHelpText>Enter the URL for this entity&apos;s Community Hub site. The URL listed here may be used elsewhere in Nimble AMS to calculate other URL based fields.</inlineHelpText>
        <label>Community Hub Url</label>
        <length>255</length>
        <required>false</required>
        <trackHistory>false</trackHistory>
        <trackTrending>false</trackTrending>
        <type>Text</type>
        <unique>false</unique>
    </fields>
</CustomObject>

Manifest: ...

    <members>NU__Entity__c.CommunityHubUrl__c</members>
    <name>CustomField</name>
</types>

....

[amguerrero]

Hi Ted,

unfortunately deltaDeployment task doesn't look inside the files that changed or what changed, it just finds out which files changed and builds the package with them.

It would be a nice feature though, as it would create a leaner and more specific package, and I will implement it in the future.