Changing the CRM database in Acoustic Campaign

Sometimes during a production or sandbox CRM integration setup, the database that is synchronizing with CRM needs to be changed. However, changing the CRM database is usually not recommended due to the inability to merge the marketing data for the old and new databases.

If you are required to change the CRM database, you could follow these steps:

1. Open a support case with the following description. Clear the CRM database for:
   • Organization: Enter your organization name.
   • POD: Enter your pod number.
   • Org ID2: Enter your Org ID.
   • Current RM DB is set to: Enter your database name.
2. Enter a reason for the database change request.

The case will be assigned to the CRMi and provisioning teams for review and completion.

The boolean data type

When planning your flexible database for CRM integration the data type matching is very important. If CRM boolean or two option fields are included it is best to plan how to translate their values between Campaign and CRM.

The best method to match the fields and account for NULL values is to use a CHOOSEBYVAL function list in Scribe Online in both directions, regardless of the field format in CRM or the field type in Campaign.

CHOOSEBYVAL evaluates a list of values and returns the result associated with the first value that is equal to the expression. If no value is matched, the default result is returned. If no default result is specified, the record error is returned. An optional single default result at the end of the list is the default if none of the values is a match.

For example, consider the following sample code, in which the synchronization direction is from Campaign to CRM:

CHOOSEBYVAL( IMCDB_Contact.Field, 'IMCTrueValue', True, 'IMCFalseValue', FCHOOSEBYVAL( crmentity.field, True, 'IMCTrueValue', False, 'IMCFalseValue', NULL, NULL )	alse, NULL, NULL )

As shown in the sample code, if the Acoustic Campaign value is true, then the function indicates the CRM to use the True option, If the IMC Value is False, the function indicates the CRM to use the False Option. If the Campaign value is Null, the function indicates the CRM to use NULL. Similarly, consider the following sample code, in which the synchronization is from CRM to:

CHOOSEBYVAL( crmentity.field, True, 'IMCTrueValue', False, 'IMCFalseValue', NULL, NULL )

As per the sample code, if the CRM option is true, the function indicates the Campaign to use the True value, If the CRM option is False, the function indicates Campaign to use the False value. If the CRM field is NULL, the function indicates Campaign to use NULL.

Use a flexible database for CRM integrations

The best practice for a CRM integration is to create a new Campaign flexible database that will be mapped and populated through either the Salesforce, Microsoft Dynamics CRM, or SugarCRM CRMi products that Campaign has developed. Using an existing restricted database is not supported for CRM integrations.

If you have an existing pre-populated Campaign database, consider the following three likely scenarios when evaluating the possibility of using it for CRM integration. These scenarios are why we recommend starting a new CRM integration with a new flexible database.

1. The existing Campaign database is a restricted database. This type of database is ineligible for CRMi, nor can it be converted into a flexible database. You must create a new flexible contact database.
2. The existing Campaign database is flexible, and overlap exists between the campaign database and your CRM (leads/contacts). While it is a flexible database, expect duplication to occur when the overlap syncs across to the opposite system. The amount of duplicates that will be created is dependent on how much pre-existing overlap exists between CRM and Campaign. You should analyze the overlap to determine if the extent of expected duplication exceeds what you are willing to accept.
   • For example, if bob@acoustic.com exists in your CRM and also in the existing Campaign database (that is overlap). The CRMi doesn't recognize that these should possibly be synchronized together because sync logic relies on the exchange of CRM ID/Campaign ID's as well as other system fields to establish the sync.
   • If the existing CRM bob@acoustic.com is synchronized to Campaign, it will create another contact in Campaign.
   • If the existing Campaign bob@acoustic.com is synchronized to CRM, it will create a new lead.
     
     The alternative is to create a new flexible database and allow the sync to perform the necessary ID and system field exchange during synchronization. Any contacts you may have that are not in your CRM can be imported directly into Campaign thereafter and will sync to CRM as new leads according to your sync rules within Campaign.
3. The existing contact database is flexible and no overlap exists between the campaign and your CRM (leads/contacts). In this scenario, if you were to use this Campaign database for integration, expect your CRM (leads/contacts) to sync and create new contacts in Campaign, while any of the existing contacts in Campaign would be synced to CRM as new leads per your sync rules. They would be created as new (unique) records and not duplicates since they previously didn't exist in the opposite system.

Note: When creating a new Campaign database for CRMi, the previous non-integrated Campaign database can remain intact, but its contacts and their marketing history remain in the non-integrated Campaign database.

Use an existing prepopulated flexible database for CRMi

The best practice when beginning a CRM integration project is to create a new Acoustic Campaign Flexible database that will be mapped and populated through either the Salesforce, Microsoft Dynamics CRM or SugarCRM CRMi products that Campaign has developed. If you are an existing Campaign client or started using Campaign in advance of the integration project, you may already have a Campaign database that you would like to sync with your CRM. If you have an existing Campaign database, the following are three scenarios that are likely. You can evaluate and decide based on the scenarios that apply to you.

A Campaign database that was not set up as a flexible database is not eligible for CRMi. The CRMi integration platforms use Campaign API that requires the Campaign database to be a single opt-in/regular opt-in (AND) be a flexible database. However, chances are that there exists an overlap in terms of contacts between your non-integrated CRM and the Campaign databases. This overlap does not sync together automatically, these records will create new records when synchronized to the other system.

• For example, let's say bob@acoustic.com exists in your CRM and also in the Campaign database The CRMi doesn't know that these should possibly be synchronized together because the CRMi didn't create them.

  • If the CRM bob@acoustic.com is synchronized to Campaign, it will create another contact in Campaign.

  • If the Campaign email address of bob@acoustic.com is synchronized to CRM, it will create a new Lead. Even though there may be another Lead or Contact for bob@acoustic.com.

  When creating a new Campaign database for CRMi, the previous non-integrated Campaign database can remain intact, but its contacts and marketing history remain in the non-integrated Campaign database.

Campaign system field data exposure in CRM integrations

When you are using a Flexible database for CRM integrations, there are two system fields that are hidden from the user interface to make sure that records are unique.

Symptoms

Exposing Campaign System Field data in CRM integrations.

Solution

• CRMSyncID (IMC version) = leadID or contactID(CRM version).
• RecipientID (IMC version) = SilverpopID or sp_engageid (CRM version).

However, you can expose the data by creating extra fields in your Acoustic Campaign flexible database.

• CRMSyncID > CRMID
• RecipientID > CAMPAIGNID

After you create the fields in Campaign, use Scribe online to double map the fields. Remember to Reset the Metadata before you try to map the new fields. Once to the actual system field and again to the custom fields you created to expose the data.