Some links are affiliate links. If you sign up, Flowpaja may earn a commission at no extra cost to you.
A form can show a perfectly readable amount while the receiving module rejects it as an invalid number. More dangerously, a conversion can succeed while producing a different amount. A type check catches the first problem; a meaning check catches the second.
Take the fictional answer 1,234. Without an input contract, you do not know whether the comma groups thousands or separates a decimal. Removing it is a decision about the amount, not just cleanup. Guessing that decision inside a mapping formula creates a plausible result that is difficult to detect later.
Define the accepted format before writing the converter. Then prove that the original answer, parsed value and destination type agree. Treat currency, missingness and allowed ranges as part of the same contract rather than repairing them after a red module appears.
Locate the real numeric boundary
Open the failed execution and identify the named parameter. If it expects a row number, contact identifier or quantity, trace that parameter's mapped value back to its producer. Converting a nearby budget answer cannot repair a missing row number.
Next inspect the type. A question collection can contain a label, metadata and an answer. The collection itself is not a scalar amount. Select the answer value inside it. A range label such as 10k+ is also different from an exact amount, even when a human knows what the label means.
Keep a raw-answer field in a disposable test destination. That gives you a comparison when the parsed value looks reasonable. Make's item data types reference describes the distinction between text, numbers and collections.
State what the form accepts
A simple contract might allow a nonnegative dot-decimal amount without currency symbols or grouping. Under that rule, 1234.56 is valid, 0 is valid if the business permits zero, and a currency-prefixed string is rejected or sent to review.
A different form might explicitly accept comma decimals without grouping. That form uses a different converter. Neither contract should be a universal parser for arbitrary locale conventions.
Write down the currency separately, even if the form accepts only one. Removing a euro sign does not convert euros into dollars. Define whether decimals and negatives are permitted, whether a maximum exists, and whether omission means unknown or zero. These constraints are business rules beyond the syntax of a number.
Prefer a numeric form field when it can enforce the intended contract. Still inspect an actual response: the representation delivered to Make matters more than the appearance of the form control.
Convert only after input checks
For plain dot-decimal text, Make's math function reference documents parseNumber(number; decimal separator). A literal diagnostic can use:
{{parseNumber("1234.56"; ".")}}
Replace the literal with the selected answer token only after that diagnostic works. For a comma-decimal contract, the specified separator changes accordingly. When the trigger already supplies a Number, use that Number directly where the destination accepts it.
Put empty and format checks before the module containing the conversion. A filter after the failing expression cannot prevent the expression from being evaluated. A diagnostic Set variable module can expose the converted value, but its own conversion must also be protected by those earlier checks.
Do not use a formatting function as a conversion function. A display value with separators belongs in a message; the amount used in a numeric API field should remain numeric.
Grouping needs a declared rule
If a form deliberately accepts US-style grouped text, a validated 1,234.56 can have its grouping commas removed before parsing with a dot decimal. For a declared dot-grouped, comma-decimal format, remove the grouping dots and preserve the decimal comma instead.
The order matters because the same character can play a different role. A blanket “remove punctuation” formula can turn 1234,56 into 123456. Stripping every nondigit also loses the sign of a negative amount. Both outputs may satisfy a destination's Number type while violating the original answer.
Space grouping deserves its own test. Ordinary spaces, nonbreaking spaces and narrow spaces are different characters. A formula targeting an ordinary space does not necessarily remove the character a visitor pasted from another application. Constrain the form or normalize the exact declared character; do not silently broaden the accepted format.
Preserve the meaning of an empty answer
Required amounts should stop the write when missing. Optional amounts should stay unknown if that is the business rule. A zero fallback is appropriate only when omission actually means zero.
ifempty() handles an empty value; it is not an exception handler for a nonempty answer such as TBD. A valid-looking fallback does not excuse a failed validation contract.
Update behavior adds another distinction. Make update modules skip empty values by default, preserving the current field. To deliberately clear it, use the erase keyword. Test the destination's exact numeric field and connector clearing behavior before enabling an explicit-clear route. Separate a missing new answer from a request to delete a previously known amount.
Make the acceptance table prove magnitude
For every test, record the original text, its declared format, expected numeric value, actual numeric value and final destination type. Use fictional values in a disposable file or record.
Include a normal decimal, a large grouped amount on the appropriate route, zero, whitespace, a blank, a permitted negative and an out-of-range value. Also include a collection and TBD. The last two should not quietly become plausible amounts.
Test a numeric threshold at the boundary as well. With a “greater than 1000” rule, 1000 belongs on the nonmatching side and 1000.01 belongs on the matching side. Confirm you selected a numeric operator. This reveals mistaken comparison types as well as mistaken parsing.
Inspect the receiving system
A cell displaying currency does not prove that the next module will read a Number. Inspect the next module's actual input, and where necessary use an unformatted numeric value rather than the display string.
For typed Google Sheets API data, numberValue requires a JSON number, not a quoted formatted amount. Serialize it with the correct type. Keep the currency and raw answer available during testing so an apparently successful write can still be audited.
Retrying unchanged invalid input repeats the same problem. Fix the contract or mapping first, then rerun the boundary test and inspect the destination. The full guide supplies the format-specific examples. If you need a scratch scenario, start with Make and prove one amount before processing a whole form queue.
Top comments (0)