Details about this thread
  • State Not Answered
  • +1 person also asked this people also asked this
  • Replies 9 replies
  • Subscribers 321 subscribers
  • Views 213 views
  • Users 0 members are here
Related content from around SugarClub

Best practice to match a core Dropdown field between modules

Tony Romano

Hi all,

What is the best practice to match a core Dropdown field between modules, when it only exists in one module OOTB?

I'm sure this comes up often enough, so wondering how others address this issue.

example; the Industry dropdown in Accounts is very useful, however it doesn't exist OOTB in any other module, i.e. Leads, therefore if you add industry_c into Leads using the same Dropdown it won't carry over during conversion.

If configuring a new Sugar instance, we simply create industry_c in Accounts module to solve this but on an existing instance where the OOTB field has been used for many years on thousands of records it would require a lot of work to both migrate the data from industry to industry_c field, and also update all the reports that use it.

I'd be very interested to hear how others manage this, and if Sugar product team has this field and others under consideration to resolve the issue?

Parents
  • 0

    Hi  ,

    If you're referring purely to the use case of lead conversions, it is an easy code-level change to the ./custom/modules/Leads/clients/base/layouts/convert-main/convert-main.php file. In that file you can map any field from the lead record to another field in the account, contact, etc. For each module enabled for lead conversion, there will be a corresponding fieldMapping array. Locate the array for the module you want to update and add the new mapping to the bottom like the following:

    'fieldMapping' => 
array (
  'name' => 'account_name',
  'billing_address_street' => 'primary_address_street',
  'billing_address_city' => 'primary_address_city',
  'billing_address_state' => 'primary_address_state',
  'billing_address_postalcode' => 'primary_address_postalcode',
  'billing_address_country' => 'primary_address_country',
  'shipping_address_street' => 'primary_address_street',
  'shipping_address_city' => 'primary_address_city',
  'shipping_address_state' => 'primary_address_state',
  'shipping_address_postalcode' => 'primary_address_postalcode',
  'shipping_address_country' => 'primary_address_country',
  'phone_office' => 'phone_work',
  'industry' => 'industry_c',
),

    Chris

    Co-Founder | SugarCRM's 2024 Global Outfitters Partner of the Year

  • 0 in reply to Chris Raffle

    thanks  

    I'm not a dev, but does your suggested code need to be updated every time we add another custom field to Leads that needs its value carried over to the matching custom field in Accounts? 

    I'm asking because you've included the standard address fields for which the values already come across OOTB.
    I notice your example is mapping both the billing and shipping addresses to primary address fields, hence I'm even more confused.

  • 0 in reply to Tony Romano

    Hi  ,

    The file only needs to be updated for fields that do not have a matching name between the modules. The address and phone number fields in my example are in the original lead conversion file generated by Sugar because those field names do not match, so the only change necessary is appending the industry field to the existing array generated by Sugar. 

    Chris

    Co-Founder | SugarCRM's 2024 Global Outfitters Partner of the Year

Reply Children
No Data