Lead Campaign Data

I feel I must be doing something wrong here.

When a Lead is created after filling out a Form it often will have Campaign Log data.

I reported a problem to Support that when the Lead is converted, the Campaign Log data does not follow to the new Contact.

I was told this is a known defect and given a link to the bug. Notice below, this was reported almost 5 years ago!

So, assuming this is never going to be fixed, does anyone have any suggestions of how to do this better?

What the Lead has done until conversion is important, losing it (without having to view the Lead and Contact both to get the data) seems crazy.

Where am I going wrong?

Parents
  • As a workaround you could write a tiny logic_hook for Leads after_save which corrects the campaign_logs after a lead conversion. I attached a module loader package with such a tiny logic_hook, to show how it works.

    The main code of the hook:

    		if($event=="after_save"){
    			if (($arguments['isUpdate'] == 1)
    			&&  (!empty($arguments['dataChanges']) )	
    			&&  (!empty($arguments['dataChanges']['converted']) && 
    			     ($arguments['dataChanges']['converted']['before']==0) && 	
    			     ($arguments['dataChanges']['converted']['after']==1)) 	
    			&&  (!empty($arguments['dataChanges']['status']) && 
    			     ($arguments['dataChanges']['status']['before']!="Converted") && 	
    			     ($arguments['dataChanges']['status']['after']=="Converted")) 	
    			&&  (!empty($arguments['dataChanges']['contact_id']) && 
    			     ($arguments['dataChanges']['contact_id']['after']!="Converted")) 
    			) {
    				$LeadId = $bean->id;
    				$ContactId = $arguments['dataChanges']['contact_id']['after'];
    				$db = \DBManagerFactory::getInstance();
    				$query = "UPDATE campaign_log ".
    				         "SET target_type='Contacts',".
    						 "    target_id=".$db->quoted($ContactId)." ".
    						 "WHERE target_type='Leads' ".
    						 "AND   target_id=".$db->quoted($LeadId);
    				$results = $db->query($query);
    			}
    	    }
     

    The module loader package:

    2045.MoveCampaignlog.zip

    Harald Kuske
    Principal Solution Architect – Professional Services, EMEA
    hkuske@sugarcrm.com
    SugarCRM Deutschland GmbH

  • Hello Harald,

    Thank you for the zip extension!

    Let me ask about the UPDATE query I see in the code.

    The Sugar Cloud Policy Guide (https://support.sugarcrm.com/Resources/Sugar_Cloud_Policy_Guide/  ) says 
    "SugarCloud customers do not have direct access to the database supporting their instance, and it is forbidden to install any utility which circumvents this restriction. "

    Can we use PHP-based zip extensions to run necessary UPDATE queries in Sugar Cloud or such approach we can employ for on-premise customers only?

    Best Regards,
    Dmytro Chupylka

    integroscrm.com
    We make work in Sugar CRM system faster, more convenient and efficient

  • Hi Dmytro,

    as a responsible developer you know the difference between direct database access and the usage of the database manager described in https://support.sugarcrm.com/Documentation/Sugar_Developer/Sugar_Developer_Guide_11.0/Data_Framework/Database/DBManager/ .

    Harald Kuske
    Principal Solution Architect – Professional Services, EMEA
    hkuske@sugarcrm.com
    SugarCRM Deutschland GmbH

  • Hi Harald,

    Thank you for the reply.

    I'm not a developer - I'm rather focused on Sugar configuring and not aquanted with Sugar development approaches and try to mitigate the risks of compatibility in projects - that is why I'm asking

    So, if UPDATE is in the code, and zip passes health check, then it is allowed, is it correct? 

    Thank you! 

    Best Regards,
    Dmytro Chupylka

    integroscrm.com
    We make work in Sugar CRM system faster, more convenient and efficient

  • If the ZIP passes the health check it is not breaking any obvious rules. Sure if you want you can always add some destructive code, but that is not wanted either by the developers nor the customers nor Sugar. The code you install should always be tested locally by the developer and in a sandbox before you bring it to a productive instance.

    When you access the database (e.g. with the database manager) you should be sure that the code will not destroy anything in your database. In this example the possibilities to change the data by REST calls are very poor as you change values in an internal logging table. So check the code, test it and then use it, if you want.

    Harald Kuske
    Principal Solution Architect – Professional Services, EMEA
    hkuske@sugarcrm.com
    SugarCRM Deutschland GmbH

Reply
  • If the ZIP passes the health check it is not breaking any obvious rules. Sure if you want you can always add some destructive code, but that is not wanted either by the developers nor the customers nor Sugar. The code you install should always be tested locally by the developer and in a sandbox before you bring it to a productive instance.

    When you access the database (e.g. with the database manager) you should be sure that the code will not destroy anything in your database. In this example the possibilities to change the data by REST calls are very poor as you change values in an internal logging table. So check the code, test it and then use it, if you want.

    Harald Kuske
    Principal Solution Architect – Professional Services, EMEA
    hkuske@sugarcrm.com
    SugarCRM Deutschland GmbH

Children
No Data