Our connector only communicates with the following standard Marketing objects in Salesforce :

In addition, it will never delete objects from your instance. Indeed, our connector's purpose is to push your event registration data, and for this purpose it will only create or update the entities listed above.

Participants will be pushed to Salesforce as campaign members. You therefore need to indicate the Salesforce campaign to which they will be associated.

This is the campaign identifier Eventmaker needs. You can retrieve it by copying the 18 characters that make it up from your browser's URL bar when you are on the campaign page.

Then you can paste it into the dedicated field in the form.

Person Accounts store information about individual people by combining certain Account and Contact fields into a single record in Salesforce. Check the box below if your Salesforce instance uses this option so the data flow between the two platforms adapts to this use case.

Once enabled, you can specify a record type for Account creation.

You have two possible choices:

It is not required to send all event participants to Salesforce. Simply indicate the participant categories concerned via the dropdown list.

The pushing of participants to Salesforce is handled by our Automation tool; four processes are configured automatically for you and can be accessed in read-only mode.

However, you can disable them individually. For example, if you do not wish to push participant attendance information, you can disable the process triggered when a participant attends.

The campaign member status indicates the progress of the guest in their participation in the event. Initially, the guest is not registered, then they can be registered, and finally they can be attended. Each of these three states must be mapped to a Status value in Salesforce.

By default we use the native Status field. But you can use a custom field you have created previously on your instance.

And for each of the three states, specify the corresponding value in Salesforce.

Warning: when you specify references to Salesforce fields or field values, you must always enter the API Names.

It should also be noted that the information that a participant is not registered is only sent to Salesforce when the participant is deleted. Indeed, the participant is only pushed to Salesforce for the first time when they reach the Registered status on Eventmaker.

In order to update data in Salesforce, we must determine which participant information needs to be pushed to the CRM and where.

For example, you will typically want the Eventmaker field first_name to populate the FirstName field in the Contacts or Leads table. Or the company's country to populate the BillingCountry field in the Accounts table.

Therefore you must set up four mapping tables (three if you do not use Leads).

The user interface offers two input modes :

Regardless of the selected mode, for each field to map you must provide 4 pieces of information :

When the connector analyzes a participant's data, each mapping table will allow it to construct the API request bodies according to what has been defined.

It is entirely possible for the connector to populate Salesforce custom fields (whose API Name typically ends with __c) in addition to native fields.

In addition, it supports Text fields, Picklist fields, Checkbox fields, and Date/Time fields.

Before pushing data to Salesforce, we must be able to determine whether it is a creation or an update of an entity.

To perform this reconciliation, we use a uniqueness key (or deduplication key) that uniquely represents the entity in Salesforce. If the connector finds a record in Salesforce matching the key it calculated, then it will update that record, otherwise it will create a new one.

There is a uniqueness key for Contacts and Leads, for which the default field is Email, and for Accounts, for which the default field is Name.

Let's continue with an example.

Assume there is in Salesforce a Contact 1 and a Contact 2 with respective email addresses contact_1@mail.com and contact_2@mail.com. A participant registers on Eventmaker with the email contact_2@mail.com; they will therefore be linked to Contact 2, which will be updated. Now another participant registers with the email contact_3@mail.com: since no contact record exists in Salesforce with that address, a new contact is created.

However, you may want to define a finer deduplication. For this you can use a Merge Field which will consist of a set of participant information concatenated and normalized. In that case, you must create a new custom field in Salesforce whose value will come from a formula that is evaluated at each update of the entity; you must also enable uniqueness for this field to ensure the absence of duplicates in the CRM beyond the scope of this integration.

Several things must be defined :

It should also be noted that the resulting value will necessarily be lowercase and that leading and trailing spaces of component values will be removed before any potential replacement.

Typically, we recommend a uniqueness key composed of Name and Email for Contacts and Leads, and composed of Name and Postal Code for Accounts.

Let's finish with an example that will probably be clearer.

A participant Inès du Pré with the email ines-du-pre@mail.com has just registered. The Contact uniqueness key is composed of the email and the name in that order, the separator is the hyphen (-), accents must be removed, no special characters are to be removed, and the dot character (.) is to be replaced by the word dot.

For reconciliation, we will search in Salesforce for a Contact whose uniqueness key is: ines-du-pre@maildotcom-du-pre.

If a Contact is found, it will be updated; otherwise, depending on the configuration, either we will search for a Lead using a (potentially different) uniqueness key, or a new Contact will be created.

Here are the steps to arrive at this result :