Modify in Connection Creator

Advertisers rarely accept your data as it is. A phone number needs a prefix, a date needs a different format, your full-time has to become their employed. The Modify Field node is where that happens.

Put it before the request, not inside it. Building values in the HTTP node works, but when something arrives wrong at the other end you have nowhere to look. Keeping the transformation in its own node means you can open the run and see exactly what went in and what came out.

How the node is organised

One node holds as many sections as you need, and each section is one target field.

Inside a section you define what happens to that field:

• Source, where the value comes from. Usually the field itself, but it can be another field, or the result of an earlier step in the same section.
• Condition, when the change should apply. Use Always when it should always happen. See Condition Operators and Field value.
• Modification, what to do with the value. See Modify Field for the full list of operations.
• Output, the result, for operations that need one.

A section can hold several of these. That is how you map a list of values: one line per value, all in the same section, each with its own condition.

Field: {income_type}

  equals  full-time       →  employed
  equals  self-employed   →  self-employed
  equals  pension         →  pensioner

One node, one place to look, instead of a branch per value.

Order fallbacks deliberately

Modify Field processes the lines in a section from top to bottom. Each later line works with the value as it exists at that point, so the position of a fallback matters.

If the fallback is unconditional, or its condition would still match a value produced by an earlier rule, put it first. The more specific rules can then override it.

Field: {income_type} 1. fallback → other 2. equals full-time → employed 3. equals self-employed → self-employed

Do not put that kind of fallback last. It would also run after a successful mapping and could replace the mapped value. A fallback can go last when its condition identifies values that are still unmodified. This can be cleaner than explicitly listing every value that should not match the fallback.

Field: {data_bank_code} 1. 2010 → 1 2. 0100 → 3 … last: matches ^\d{4}$ → 1

Here, a known code such as 2010 becomes 1, so it no longer matches ^\d{4}$. An unknown code such as 9999 remains unchanged, still matches the final rule, and receives the fallback value.

The important rule is not that a fallback must always be first or last. Place it so that its condition cannot match and overwrite a value that was already transformed successfully.

Building a value in steps

The lines in a section run in order, and a later line can take the output of an earlier one as its source. That is how you build a value in stages instead of looking for one operation that does everything.

Field: {created_date}

  1.  source: {created_date}   modify date   →  +30 days
  2.  source: step 1           format date   →  d.m.Y

The second line formats the date the first line produced. Pick the earlier step in the Source setting, the same way you would pick a field.

Keep this in mind when writing conditions. A condition on the second line is checked against whatever that line’s source holds at that moment, which may no longer be what the field contained when the node started.

Common uses

• Translating values. Their vocabulary instead of yours, as above.
• Keeping a number within the advertiser’s range. A numeric field can carry a value the advertiser will not accept. If they lend up to 20 000 and your form allows more, replace anything above that with 20 000, so the request goes through with the highest amount they can actually work with.
• This is about the value in one field, not about how many leads an advertiser receives. For that, see Lead and Click Capping.
• Filling empty required fields. Some advertisers reject a request outright when a field is missing, even one they do not care about. Put a placeholder in.
• Reformatting. Prefixes, date formats, splitting or joining values.
• Leaving a field out entirely. Sometimes an empty value is worse than no value. Use do-not-send to drop the field from the request instead of sending it blank.

Watch the braces

A reference goes in braces, as {parsedBody.name}. Written without them it is a plain string, so a condition can never match it and the whole section silently does nothing.

This is the most common reason a Modify Field node appears to be ignored.