back to top

Converting a Lead to Contact and passing acrossed custom fields

When a Lead is converted to a Contact in the SalesLogix web client, the Lead information is passed across to the contact that is created.  The logic for this data transfer occurs in several entity level business rules at the Lead entity.   There are several rules involved including: ConvertLeadToAccount, ConvertLeadToContact, ConvertLeadAddressToAccountAddress, and ConvertLeadAddressToContactAddress.  These rules are all named pretty logically, as to there purpose.  These rules are all implemented withing the compiled Sage.SalesLogix.BusinessRules.dll assembly and therefor cannot be modified. Also, within that assembly are several private helper methods that are also not exposed for use or modification.

Since the core area can’t be modified how would you add logic to transfer custom fields from the Lead area to the Contact area?

Well lets take a step back and look at where the business rules are actually called from.  This logic is all invoked when you convert a lead to a contact which takes place from the custom smart part called  LeadSearchAndConvert.ascx with a corresponding code file of LeadSearchAndConvert.ascx.cs.  These smart parts are located in the VFS under Portal Manager…Sage SalesLogix…Support Files…SmartParts…Lead.  The relevant parts are all in the LeadSearchAndConvert.ascx.cs file, specifically in the methods called  ConvertLeadToNewAccountandContact, and ConvertLeadToContact.  The methods are called based on whether the lead is being added to an existing Account during the conversion.  If we look at the ConvertLeadToNewAccountandContact method (both are fairly similar so we should be able to see what we are talking about) we see the following:

 private void ConvertLeadToNewAccountAndContact(ILead lead, bool createOpportunity, string options)
    {
        IOpportunity opportunity = null;
        IContact contact = EntityFactory.Create<IContact>();
        IAccount account = EntityFactory.Create<IAccount>();
        string leadHistoryId = string.Empty;
        ILeadHistory leadHistory = null; EntityFactory.Create<ILeadHistory>();
        leadHistoryId = lead.SaveLeadHistory();

        lead.ConvertLeadToContact(contact, account, options);
        lead.ConvertLeadToAccount(account);
        lead.ConvertLeadAddressToAccountAddress(account);
        lead.ConvertLeadAddressToContactAddress(contact);
        account.Save();
        contact.SaveContactAccount(account);

This is only the beginning of the method but shows us the important parts.  Specifically, in code a new Account and Contact entity are established (The first 2 highlighted lines).  Then the lead business rules are called (the second set of highlighted lines).

Now that we see how the rules are called we have two options.  One would be to add our code right to these methods in the LeadSearchAndConvert.ascx.cs file. We could do that by adding code like shown highlighted here: 

    private void ConvertLeadToNewAccountAndContact(ILead lead, bool createOpportunity, string options)
    {
        IOpportunity opportunity = null;
        IContact contact = EntityFactory.Create<IContact>();
        IAccount account = EntityFactory.Create<IAccount>();
        string leadHistoryId = string.Empty;
        ILeadHistory leadHistory = null; EntityFactory.Create<ILeadHistory>();
        leadHistoryId = lead.SaveLeadHistory();

        lead.ConvertLeadToContact(contact, account, options);
        lead.ConvertLeadToAccount(account);
        lead.ConvertLeadAddressToAccountAddress(account);
        lead.ConvertLeadAddressToContactAddress(contact);
        contact.CustomProperty = lead.CustomProperty;
        contact.CustomProperty2 = lead.CustomProperty2;
        contact.CustomProperty3 = lead.CustomProperty3;
        account.Save();
        contact.SaveContactAccount(account);

Adding this code will alter the Contact entity that has been established and then populated via the Lead business rules.  Placing our code where it is puts it after the Business Rules run and before the Account and Contact entities are actually saved.

As an alternative to this we could modify the business Rules themselves, adding a Post Execute event.  You can see the business rules have some input parameters.  For instance the ConvertLeadToContact rule passes in three parameters, an instance of the account, contact, and options objects.  That means from within the business rule you could add the exact same set of code we added directly to the user control code file:

    contact.CustomProperty = lead.CustomProperty;
    contact.CustomProperty2 = lead.CustomProperty2;
    contact.CustomProperty3 = lead.CustomProperty3;

 Either way will allow your custom Lead data to pass across to the Contact that is spawned from the Lead upon Conversion.  Of course you can extend this in other ways to besides just one to one field mappings.  With an understanding of where and how the conversion happens, the rest is up to you.

Contact Customer FX for your CRM project
We let our expertise speak for itself - let us know how our all-star team can help on your CRM project
About the Author
Kris Halsrud
Kris Halsrud
Kris Halsrud is a Senior Analyst / Developer for Customer FX Corporation.

LEAVE A REPLY

Please enter your comment!
Please enter your name here

Infor CRM Sync for Exchange: Action Required by August 31, 2026

Using Infor CRM Sync for Exchange with Microsoft 365? Your Exchange administrator must update tenant settings by August 31, 2026 to prevent sync disruption.

[Webinar] What’s Coming Next for Infor CRM SLX and Why v10 Matters

See what’s coming next for Infor CRM SLX, including new marketing workflows, automation improvements, and reasons to consider upgrading to v10.

Disable Caching in Infor CRM SLX Web Client

In the rare case caching is causing issues in the Infor CRM SLX web client, it is possible to disable specific types of caching by making edits using Application Architect, and then deploying.

Exploring AI Options for Infor CRM v10

I've started taking a closer look at the AI capabilities built into Infor CRM v10. Over the next several posts, I'll share what I learn. From the built-in features and supported AI providers to implementation considerations, costs, and practical use cases.

Infor CRM SLX 10.0: Delegate Ownership Changes for “Everyone” Records

Learn how the new EveryoneOwnerAssignment secured action in Infor CRM SLX 10.0 allows designated users to change ownership of Everyone-owned records without requiring Administrator access.

Related Articles

Infor CRM Sync for Exchange: Action Required by August 31, 2026

Using Infor CRM Sync for Exchange with Microsoft 365? Your Exchange administrator must update tenant settings by August 31, 2026 to prevent sync disruption.

[Webinar] What’s Coming Next for Infor CRM SLX and Why v10 Matters

See what’s coming next for Infor CRM SLX, including new marketing workflows, automation improvements, and reasons to consider upgrading to v10.

Disable Caching in Infor CRM SLX Web Client

In the rare case caching is causing issues in the Infor CRM SLX web client, it is possible to disable specific types of caching by making edits using Application Architect, and then deploying.

Exploring AI Options for Infor CRM v10

I've started taking a closer look at the AI capabilities built into Infor CRM v10. Over the next several posts, I'll share what I learn. From the built-in features and supported AI providers to implementation considerations, costs, and practical use cases.

Related Videos