Salesforce – How to retrieve and deploy Lead mapping?

There are projects where I work on lead conversion and I have to move lead mapping from one sandbox to another (or production). As I do it quite rarely, I always have to Google how exactly should I do it.

This post is my memo about doing it using ANT.
I assume that you have it installed. If not – there’s a good tutorial (Ant Migration Tool Guide)

package.xml

<?xml version="1.0" encoding="UTF-8"?>
<Package xmlns="http://soap.sforce.com/2006/04/metadata">
    <types>
        <members>*</members>
        <name>LeadConvertSettings</name>
    </types>
    <version>40.0</version>
</Package>

LeadConvertSettings is available in API versions 39.0 and later.

One thing to keep in mind is that all of the fields that take part in the lead conversion process should already exist on destination org or be a part of the current package.

4 thoughts on “Salesforce – How to retrieve and deploy Lead mapping?

  1. Grzegorz,

    Thanks for helpful quick article, but how do you remove/unmap LeadConvertSettings mappings (change them back to “None”, e.g. prequisitite to mass delete the fields)? I’ve searched all over the web and no one seems to be able to figure this out.

    Many people (including myself) were under the impression you have to use destructivechanges.xml plus a default package.xml file (with no components listed) to perform a destructive change. But is it actually just a regular package.xml deployment, because technically you can’t “delete” standard object fields or settings themselves; you’re just changing the values?

    The mystery is that package.xml components seem to only use , , and tags. But each LeadConvertSettings mapping has a more complicated hierarchical structure similar to below, so it would seem you’d need to specify all of these things:

    – inputObject (e.g. Lead)
    – inputField
    – outputField
    – outputObject (e.g. Contact)

    Lead

    CustomLeadFieldToUnmap__c
    CustomLeadFieldToUnmap__c

    Contact

    LeadConvertSettings

    Could you please explain and provide some examples with both standard and custom Lead fields of how you could use package.xml and/or destructivechanges.xml (whichever are the correct ones) to set a mapped Lead field back to “None”?

  2. (sorry, re-posting as XML snippets got treated as code in OP)

    Grzegorz,

    Thanks for helpful quick article, but how do you remove/unmap LeadConvertSettings mappings (change them back to “None”, e.g. prerequisite to mass delete the fields)? I’ve searched all over the web and no one seems to be able to figure this out.

    Many people (including myself) were under the impression you have to use destructivechanges.xml plus a default package.xml file (with no components listed) to perform a destructive change. But is it actually just a regular package.xml deployment, because technically you can’t “delete” standard object fields or settings themselves; you’re just changing the values?

    The mystery is that package.xml components seem to only use <name>, <members>, and <types> tags. But each LeadConvertSettings mapping has a more complicated hierarchical structure similar to below, so it would seem you’d need to specify all of these things:

    – inputObject (e.g. Lead)
    – inputField
    – outputField
    – outputObject (e.g. Contact)

    for example:

    “`xml

    Lead

    CustomLeadFieldToUnmap__c
    CustomLeadFieldToUnmap__c

    Contact

    LeadConvertSettings

    .“`

    Could you please explain and provide some examples with both standard and custom Lead fields of how you could use package.xml and/or destructivechanges.xml (whichever are the correct ones) to set a mapped Lead field back to “None”?

  3. Posting here to answer my own question – the answer was so obvious, it had eluded me for a while:

    To unmap a Lead field mapping (aka, “delete” the lead field mapping) from your org, follow the instructions above to download the LeadConvertSettings metadata XML file to your org, simply delete the lines of code containing the mappings you wish to remove, then push the changes back to your org!

    (if using VS Code, you will find this file downloaded to force-app\main\default\LeadConvertSettings\LeadConvertSettings.LeadConvertSetting-meta.xml in your project folder)

    For example, you would delete these 4 lines contained within the Contact section to remove the Lead to Contact mapping for “Custom Lead Field 1”:

    Custom_Lead_Field_1__c
    Custom_Lead_Field_1__c

    Note, you need to do this using the standard package.xml, rather than destructivechanges.xml, because you’re not actually deleting a custom component; you’re simply removing (updating) metadata for a standard object.

    If you want to take the next step and then also remove the custom field from your org, you would then create a separate folder, and inside it create a destructivechanges.xml and “empty” package.xml file (containing only the package and version declarations), then push destructive changes using the SFDX command:

    sfdx force:mdapi:deploy -d [folder_containing_destructivechanges.xml_and_emtpy_package.xml] -u [username_or_alias_for_your_org]-w -1

    Note the package.xml in your root /manifest folder contains only components you’re sending or retrieving (updating, e.g. the LeadConvertSettings mappings). The destructive changes folder such as /destroy must contain 2 files: an “empty” package.xml file and a destructivechanges.xml for the components you’re deleting (e.g. the custom field itself).

    References:

    Sample package.xml Manifest Files:
    https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/manifest_samples.htm

    Deleting Components from an Organization
    https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_deploy_deleting_files.htm

Leave a Reply

Your email address will not be published. Required fields are marked *