LeadConduit: Advanced Field Mapping

« Previously: Filters

LeadConduit supports complex field and value manipulation so you can account for all the real-world complexity of lead data. The following are a few of the common "power user" configurations we use often: 



Conditional Rules

Some steps or sets should only execute when a set of conditions is met.

In the scenario below, Campaign ID will be set to the value DoctorWho only when the Lead Source is TARDIS.





Order of Operations

All the steps in a flow and all the mappings in a step execute in the order listed from top to bottom until the flow reaches the Success point or a filter stops the flow.

This means you can set a catch-all field mapping first, then override it with a specific field mapping with Conditional Rules.

In the scenario below, Campaign ID is set to the value 01234 for all leads unless the Lead Source is TARDIS, then the Campaign ID is set to DoctorWho.




Copy Field Mapping

When you need to create a moderately complicated field mapping over and over, it's helpful to build out all the generic pieces first.


Then you can copy the field mapping, fill in the specifics, and Save.



Server Response Content Type Override

The Accept request HTTP header advertises which content type(s) the client is able to understand. Using content negotiation, the server selects one of the proposals, uses it, and informs the client of its choice with the Content-Type response header.

Sometimes the content type does not match the content, causing built-in tools like dot notation for XPath and JSON Property accessors to fail.

In the example below, the server is advertising JSON as plain text.



POST https://service.whatever.whatever/post/json/api/v1 HTTP/1.1
Content-Type: application/json; charset=utf-8
Accept: application/json;q=0.9,text/plain;q=0.5
Host: service.whatever.whatever

  "username": "user",
  "apikey": "password",
  "fName": "Mike",
  "lName": "Jones",
  "zip": "78751",
  "city": "Austin",
  "state": "TX",
  "address": "123 Main Street",


HTTP/1.1 200 OK
Date: Mon, 21 Nov 2016 21:14:30 GMT
Content-Type: text/html; charset=UTF-8
Content-Length: 93
Connection: close
Server: Apache/2.4.16 (Ubuntu)
Vary: Accept-Encoding
Access-Control-Allow-Origin: *

        "API credentials are invalid",
        "Invalid Email",
        "invalid email"

LeadConduit allows you to manually override the content-type so you can make use of dot notation instead of needing to write complex regex. In this example we're overriding text/html to application/json so we can use dot notation to capture the reason from the Messages object.




Customized Timestamps

LeadConduit allows for the creation of virtually any timestamp format by concatenating (“stringing together”) the various components in time-related drop-down menus.

For example, suppose a user wants to deliver the Submission Timestamp in this format:


Although this option isn’t immediately available in the drop-down menu, users can manually create the desired format by stringing together the individual timestamp components. In this example, the user would first select the MM-DD-YYYY format from the Submission Timestamp drop-down menu.

The user then adds another Submission Timestamp variable to the same flow field and selects an hour and minute format.

Once a user makes those selections, the flow field will contain the components necessary to deliver the timestamp in the desired format.




Forcing Empty Strings in Field Mapping

Forcing an empty string in outbound field mapping is helpful when you need to send a specific parameter to a delivery destination regardless of whether or not there is a value associated with that parameter.

For example, let's say you are creating a flow that delivers leads to your CRM (e.g. Salesforce, Velocify, Marketo, etc.), and you are required to send an "address_2" parameter for a successful lead delivery.

In this scenario, if the value assigned to "address_2" is "Apt. 101", you will send this information to the CRM (address_2="Apt. 101"). However, even if "address_2" is blank, you still need to send this information to your CRM because the "address_2" parameter is required. In other words, your CRM needs to receive "address_2=(this can be empty or have content)" for a successful lead delivery.

To accomplish this setup, let's first take a look at a typical delivery configuration.

In the above image, we have configured the delivery step in our flow to send the data contained in "Address 2" to the CRM via the "address_2" parameter. If a person fills out the form field associated with "address_2", our current configuration will work perfectly. The value associated with "address_2" (e.g. address_2="Suite 205") will be sent to the CRM from LeadConduit.

However, if the "address_2" field is left blank on the form, we have no rules set up to tell LeadConduit what to do with this empty parameter (address_2=). Therefore, LeadConduit will NOT send "address_2" to the CRM, ultimately ending with the CRM failing the lead.

To achieve a successful delivery and ensure address_2= is still sent to the CRM, we need to configure our step to look like this instead:

Take a look at (1). This is where we tell LeadConduit what we want it to do if the "address_2" parameter is empty. In this case, (A) if "Address 2" is left blank, LeadConduit will (B) send an empty string with the "address_2" parameter (address_2=). Now our CRM will accept the lead!

(2) is set up exactly the same way as our first example, and required to assure this configuration works properly. If there is a value associated with "address_2" (e.g. address_2="Apt.101"), (2) tells LeadConduit to deliver that data. As discussed earlier, our CRM will accept this lead.


Hiding non-required fields from the Submission Docs

You can keep a field from showing up in a source's Submission Docs by mapping that field as empty in the source's Inbound Field Mapping section (seen below) which in this case prevents address_2 from showing up in the Submission Docs.


Mapping Integers as Attributes


For a typical outbound delivery using JSON, you can simply utilize dot notation to create an object in the request body.

When mapping integers as attributes, dot notation is necessary - but not sufficient. For example, let’s assume we want to create an “opt-in” attribute that will allow the delivery of information about which opt-in language a lead saw while filling out the form. For this example, our delivery destination requires an "opt_in" attribute in the request body that looks like this: 

If we attempt to create the required request body using only dot notation, we won’t be able to create the key-value pair for “opt_in” that the delivery destination requires. LeadConduit will treat the integer as an array index - not as a key in our “opt-in” key-value pairs. As a result, our request body will be structured incorrectly.

To get the desired outcome and map the integers as attributes, we’ll need to use curly braces around the integer instead of dot notation.

By surrounding these integers in curly braces, LeadConduit is now aware we want to create a key-value pair with the integer as our key. As a result, the request body is now structured the way our delivery destination requires.

 Next: Response Parsing »

Was this article helpful?
0 out of 0 found this helpful
Have more questions? Submit a request


You must be logged in to comment.