Your Make scenario ran green and the data is wrong

The failure with no red

A scenario that stops is a scenario you can fix. There is a red module, an error message, an email, a timestamp to work back from. This article is about the other kind: the run finishes, the operations are counted, every module is green, and the value that moved was not the value you meant to move.

Here is what that looks like from the inside, from someone working through Make's own learning path in July:

Whenever filter is used in the map() function, it's returning empty result. No errors while running. The output bundle is empty. After some troubleshooting, it's confirmed that the problem isn't with the input array or the key for map. The issue is in filtering.

• a user, Why is my filter not working in the map() function on the array, Make Community, 25 July 2026

The answer, two days later, was invisible spaces. Not a syntax error, not a missing bracket - literal space characters sitting inside the values being compared.

Make's own documentation explains why nothing turned red. A filter is not a check that can fail; it is a gate:

You can add a filter between two modules and check whether bundles received from the preceding modules fulfill specific filter conditions or not. If yes, the bundles will be passed on to the next module in the scenario. If not, their processing will be terminated.

• Filtering, Make Help Center

A bundle that fails a filter is not an error. It is a bundle that has been dealt with. That single design decision is why an entire class of Make problems arrives as silence: the wrong filter and the right filter produce the same clean run.

A scenario that breaks costs you an afternoon. A scenario that quietly drops the wrong customers costs you until somebody notices, which may be a quarter later.

The editor keeps two kinds of character

The thing that catches experienced builders is that a Make formula is not text. It is a structure that happens to be displayed as text, and some of the characters you see are elements of that structure while others are just characters. On screen they look identical.

A user trying to strip a country code from a phone number in July:

Make removes the plus

{{replace(2.phone; +44; emptystring)}}

becomes:

{{replace(2.phone; 44; emptystring)}}

as soon as I save it.

• a user, Do I need an escape character? Make is deleting the + symbol from replace command, Make Community, 21 July 2026

The explanation came from a Community Champion, not from a documentation page:

The + sign is used to merge two text strings together in programing. This is why it breaks when you try it as part of something bigger.

• a Community Champion, same thread, 22 July 2026

The fix offered in that thread is to wrap the character in toString() so it is treated as a literal, described there as "the proper way at the moment". Make's function reference documents toString (value) as "Converts any value to a string" and says nothing about using it to stop an operator being read as an operator.

The same confusion shows up with the argument separator. Someone practising date formatting could not work out why Paris and New York printed the same time, and the answer had nothing to do with time zones:

The second semicolon is wrong. It's not the function one but just the text string.

• a Community Champion, Facing problem in applying date/time function, Make Community, 29 July 2026

A second contributor put it in one sentence the next day: the semicolon "was not properly encoded eg. it is normal character ;, not ; pill." Two semicolons, same glyph, different meaning, no way to tell them apart by looking.

And once more with arithmetic. A user calculating margins on Shopify line items found that round(10 / 3; 2) returned 3 rather than 3.33, and that Make sometimes returned the formula itself as plain text instead of a number. The accepted answer was to "use the native math operators, instead of like putting asterisk and forward slash".

The documentation is consistent with all three cases, though it never states the consequence:

To insert a function into a field, click the function name or drag it to the field.

• Use functions, Make Help Center

Click or drag. Not type. The documentation says that about functions; the three threads above are the community working out that the same is true of operators and of the argument separator, which are also items in that panel. A typed lookalike is a different thing that renders the same.

Everything is space-sensitive

Back to the filter that returned nothing. The accepted answer names the exact positions:

You have empty spaces. First one is two around item_name, second one is before Basic T-Shirt and item_name.

• a Community Champion, Why is my filter not working in the map() function on the array, Make Community, 27 July 2026

A second Community Champion added the rule in three words - "Everything is space-sensitive" - and the person who asked closed the thread with the detail that makes this worth an article:

I didn't pay attention to the spaces earlier, as in some places though it appeared to be a space, it cleared the previous element with a backspace.

• the thread's author, same thread, 27 July 2026

Read that carefully. What looked like a space was in fact a mapped element sitting in the field, and pressing backspace on it removed the element rather than a space. The field was not showing text; it was showing objects with gaps between them, and the gaps and the objects are visually hard to tell apart.

Two things follow, and both are worth knowing before you spend an afternoon:

• trim() does not rescue you. Make documents it as trim (text), "Removes space characters at the start or end of the text." A space in the middle of a filter operand, or between two mapped elements, is not at the start or end of anything.
• Filter operands are mapping fields. The Filtering page is explicit: "In the operand field, you can enter values in the same way as you would map them." Every invisible-structure problem that affects a formula affects a filter condition too, and the filter is the place where the consequence is silent.

A comma in your data is a separator in your formula

The most instructive thread of the month came from someone whose scenario had run successfully on a Monday and failed on the Wednesday, with nothing changed in between:

This scenario ran successfully on Monday, July 20th. It was turned off after that. I ran it again on July 22nd and it threw an error in the filters

• a user, Map() not extracting data, Make Community, 23 July 2026

Note how the failure was distributed:

It let 7 bundles through (and they successfully completed) before failing on this one.

• the same user, same thread, 23 July 2026

Seven records were processed. The eighth stopped the run. After trying trim(), ascii(), replaceEmojiCharacters(), replace() with a regular expression and the Text Parser, the person tracked it down themselves:

And now, going through all of this, I see that this seemingly happens only for Businesses whose name has a comma in it.

• the same user, same thread, 23 July 2026

Make's own function reference explains that without ever warning about it. This is the signature of map():

map (complex array; key;[key for filtering];[possible values for filtering separated by a comma])

• Array functions, Make Help Center

The last argument is a comma-separated list of values. So a company called Nolan, Baker & Co is not one value being matched - it is two, Nolan and Baker & Co, neither of which exists. The Community Champion in the thread reached the same conclusion: "When you put a comma separated list in there it treats it as separate arguments to check against, not one whole string."

Nothing about that is a defect in Make. It is documented behaviour, correctly implemented. It is also invisible in testing, because it depends entirely on punctuation inside customer data - and it lies dormant until the day somebody in sales types a company name with a comma in it. Test data rarely has commas. Real customer names, addresses and product titles are full of them.

What the screen shows is not what gets sent

The fourth pattern is the most expensive to debug, because the interface actively reassures you.

A user filing transactions into YNAB found dates arriving wrong no matter what they typed:

When I input a date into the "Date" field of YNAB's "Create a Transaction" module, the bundle always returns a serial date

• a user, YNAB "Date" Field getting automatically converted to serial date no matter what I input, Make Community, 30 July 2026

The reply that reframes the whole problem came the same day:

Make is automatically changing the formatting of the visible date to 'July 30, 2026 12:00 AM', but that is not what is send. If you hover over a formatted date, you will see the UTC timestamp

• another user, same thread, 30 July 2026

And the sentence to pin above the desk, from the same reply: "That might even differ from the actual date that it send."

The specific module bug in that thread has since been fixed - on 22 August the same user reported that Make had updated the YNAB module and that the date now works as intended. The mechanism underneath it has not changed and applies to date fields generally, which is why the thread is still worth reading.

Make documents both halves of that mechanism, on two separate pages. First, that a displayed date is a rendering:

In output bundles, date and time values are displayed based on the locale and the time zone specified in your Profile settings (Web section > Time zone options).

• Item data types, Make Help Center

Second, that this display setting has no influence at all over what actually runs:

The user time zone only impacts how Make displays information, such as the date and time displayed in module output, bundles, or a log. Changing the user time zone does not impact scenario execution.

• Manage time zones, Make Help Center

The execution-side setting is a different one, and it is organisation-wide: "The organization time zone defines scenario execution and functions such as formatDate and parseDate." So two people looking at the same successful run, in different profile time zones, can read two different dates in the same bundle - and neither of those is necessarily the value that left the building.

There is a two-second check for this, and it is the most useful sentence in Make's documentation for the whole class of problem:

You can also view a date item's value in ISO 8601 format by hovering over the item. This is the format used when passing the date values through the API to other services.

If the ISO value does not show up, the item is not a date but probably text.

• Item data types, Make Help Center

Hover a date. If no ISO timestamp appears, you are not looking at a date - you are looking at text that resembles one, and the receiving app will parse it with its own rules.

Make documents the reason it stays quiet

None of this is hidden, exactly. It is on a page called Type coercion, which nobody reads until after the incident, and it says the quiet part outright:

Make automatically coerces (i.e., converts) certain data types when possible. This helps your scenario continue running even when data types don't perfectly match (when there are minor type mismatches).

However, in some cases, this coercion may produce unexpected outputs, which can cause errors later in the scenario.

• Item data types, Make Help Center

"Helps your scenario continue running" is the design goal, and "unexpected outputs" is the price. The coercion table spells out four conversions worth knowing by heart, because each of them turns a value into a different value without complaint:

Read the first two rows again with a real field in mind. A quantity of 0 mapped into a yes/no field becomes Yes. A text value of no mapped into the same field also becomes Yes, because it is neither the word false nor empty. If that field is "subscribed", "taxable" or "in stock", the run is green and the record is wrong.

What we would check first

• Hover every date item feeding an external module and confirm an ISO 8601 value appears; if it does not, the item is text and the receiving app is parsing it with its own rules
• Re-insert operators and separators from the mapping panel in any formula that misbehaves after an edit, before rewriting the logic
• Find the filters and map() calls that match on names, titles or addresses, and switch them to IDs wherever an ID exists
• Assume commas exist in real customer data, and check what a comma does to the last argument of every map() you have
• Add a fallback route after filters that matter, so bundles that fail the condition are logged instead of terminated in silence
• Check every mapping into a yes/no field: a number of 0 and the text "no" both arrive as Yes
• Set the organisation time zone deliberately and write it down, since formatDate and parseDate follow it while your own display setting does not
• Compare the ISO values in a bundle against what the receiving app stored for the same record, on at least one record per integration

The uncomfortable part of this class of bug is that it does not announce a start date. When a scenario breaks, you know when. When a scenario quietly drops the wrong customers or writes Yes where you meant No, the first honest question is how far back it goes - and answering that is usually a bigger job than the fix. Which is the argument for doing these checks on a scenario that is working fine, the same way you would untangle a live automation before you need to.

If the run is green and the data is wrong, the problem is rarely your logic. It is almost always a character, a type or a time zone doing exactly what it is documented to do.

Sources

• Why is my filter not working in the map() function on the array, even after following the instructions right as described in the Make Intermediate Learning path? - Make Community, thread opened 25 July 2026, read 25 August 2026. The empty result with no errors, the accepted answer naming the empty spaces, "Everything is space-sensitive", and the report that what looked like a space was a mapped element removed by backspace.
• Do I need an escape character? Make is deleting the + symbol from replace command - Make Community, thread opened 21 July 2026, read 25 August 2026. The plus sign disappearing on save, the explanation that + merges two text strings, and toString() described as the proper way at the moment. The answers are from a Community Champion, not from Make staff.
• Map() not extracting data - Make Community, thread opened 23 July 2026, read 25 August 2026. Seven bundles completing before the failure, the list of transformations that did not help, the user's own finding that it happened for business names containing a comma, and the explanation that a comma-separated list is read as separate arguments.
• YNAB "Date" Field getting automatically converted to serial date no matter what I input - Make Community, thread opened 30 July 2026, read 25 August 2026. The visible date being a reformatting rather than the payload, the hover revealing the UTC timestamp, and the 22 August update reporting that Make had fixed this specific module.
• Facing problem in applying date/time function - Make Community, thread opened 29 July 2026, read 25 August 2026. The semicolon that was a text character rather than a function separator, and the follow-up naming it as a not-properly-encoded pill.
• Tools > Set multiple variables returns formula as text or empty instead of calculated numeric value - Make Community, thread opened 17 July 2026, read 25 August 2026. round(10 / 3; 2) returning 3, the formula coming back as plain text, and the accepted answer to use the native math operators rather than a typed asterisk and slash.
• Item data types - Make Help Center, page updated 24 August 2026, read 25 August 2026. Automatic coercion helping scenarios continue running, coercion producing unexpected outputs, dates being displayed per profile locale and time zone, the ISO 8601 value on hover being the format passed through the API, and the test that a missing ISO value means the item is text.
• Type coercion - Make Help Center, page updated 15 January 2026, read 25 August 2026. Number into Boolean converting to Yes even when the value is 0, text into Boolean converting to Yes unless it equals false or is empty, non-array values being wrapped into a single-element array, text into Date defaulting the time zone to your settings, and an array of collections converting to a comma-separated list.
• Array functions - Make Help Center, read 25 August 2026. The map() signature, whose last argument is "possible values for filtering separated by a comma".
• Filtering - Make Help Center, page updated 15 January 2026, read 25 August 2026. Bundles that fail a condition having their processing terminated, and operand fields taking values the same way as mapping.
• Use functions - Make Help Center, page updated 30 June 2026, read 25 August 2026. Functions being inserted by clicking the function name or dragging it into the field.
• Text and binary functions - Make Help Center, page updated 4 June 2026, read 25 August 2026. The replace() signature, trim() removing space characters at the start or end of the text, and toString() converting any value to a string.
• Manage time zones - Make Help Center, read 25 August 2026. The user time zone affecting display only, and the organisation time zone defining scenario execution and functions such as formatDate and parseDate.