Lead Campaign Data

Agree -that might never be fixed - these days copying Leads campaign data  to Contacts in Sell while having Sugar Market connected might lead to a data nightmare - due to data sync inconsistency - consider that according to my experience, conversion Lead to a Contact may additionally require substitute the converted Lead record by new Contact record in very each Target List so that Contact could successfully sync back to the Market

Regarding the Leads history not-to-forget - I'd suggest starting from this
1) define what Lead actually is - not from SUgar perspective but from  the company business perspective, - and what differs the Lead entity from the Contact entity for your company (if any difference but nurturing stage)
2) what Leads history is important for further Opp development by the SalesReps and how SalesReps will use that history - that would help to decide what Lead's history records to put in Contacts/Opps timeline and in which form - sometimes it is enough to put some Lead's data into the profile and that's all, sometimes - to arrange timeline events for contacts/Opps on the basis of Leads behavioral data from marketing

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

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?

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/ .

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! 

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.