This HTTP Request integration sends Splash data to any SFMC Data Extension in real time.
Note: DEManager is maintained by Salesforce.
On this page:
- Set up the Data Extension in Salesforce Marketing Cloud
- Set up the HTTP Request in Splash
Set up the Data Extension in Salesforce Marketing Cloud
In SFMC, go to the email section.
Find an existing data extension in the labeled tab, or use the arrows in the Shortcuts section to find Create Data Extension.
Your data extension should contain all of the fields you want to track. For example, here, we use email, first_name, last_name, event_id, guest_status text fields, a boolean called opt_in, a date field called custom_date, and another text field called activity_key which will be the primary key for the table.
Non-nullable fields will be required, and any calls that leave those fields empty will result in a failure.
Set up the HTTP Request in Splash
Configure basic settings
- In the Integrations tab in Splash, select HTTP Request.
- Under Request Settings > Endpoint, set the method to POST. The URL you'll set for the Postback URL will be some variant of http://cl.s#.exct.net/DEManager.aspx, where # is the stack number your instance resides in.
- The test instance in this example is on stack 11, so we use http://cl.s11.exct.net/DEManager.aspx.
- Next, set Content-Type to application/x-www-form-urlencoded. No headers are necessary.
- Under Triggers, select the desired attendee actions you want to trigger the integration. Here, our use case is to file guest actions to a data extension while not constraining conditions.
Configure special field mappings
The following fields are required for POST calls to the DEManager to work. All fields must be present or the calls will fail. To configure these mappings, add the fields to the Field Mappings section and click Save when you’ve added all fields.
|Example Splash Values
This is the action that the Data Extension Manager will take upon receiving the information. You can copy and paste these directly; they do not require any quotes or other formatting.
|This will always be set to 0. Splash does not require any response from SFMC.
This is statically set to Submit. Any other value will cause the POST to fail.
The success URL can be any viable URL.
|The error URL can be any viable URL.
The Client ID is found under the account dropdown in the top-right corner of the Salesforce screen, labeled as "MID." You only need the number itself.
|Every data extension will have an external key by which it can be identified. This is typically a sort of auto-generated code, but can be manually changed if you’d like to change it. On opening any data extension, you will be first taken to the Properties tab, where it can be found at the very top.
The subscriber key is a necessary field to tie the entries in the data extension to a contact or subscriber within Salesforce Marketing Cloud. This is best done via the contact email address.
Field mappings example
Configure general field mappings
Once these fields have been set up, you can map any content available to Splash HTTP Request integrations.
Keep in mind that the Data Extension must also be configured.
Required fields must be sent, and data types must match up properly. With string fields, this is simple. With other data types, certain steps must be taken for the integration to work. You can see these caveats in the table below, next to example values for creating a guest RSVP action record.
|Example Splash Values
Text fields can be directly mapped
|Boolean fields will need to be mapped — 1 to true, and 0 to false — within the value mapping dropdown on the field selector.
|Date fields carry additional complexity. SFMC DEManager will reject the data if the destination field is a date field, and the data Splash sends contains the time as well as the date. The format in this example is a successful one. In this example, a custom field question date is also tied to demonstrate how to both identify a custom question and format it.
Every data extension needs a primary key. Some clients might use the email address as this key, though this does mean that the guest status can only be updated once added the first time. So the time of an RSVP and of a check-in, for example, would need to be tracked separately.
You can alternatively create a primary key dynamically for each guest action, created from the dynamic tags for guest email, event id, and a timestamp, sent over to a string field on the SFMC DE side.