Skip to main content
The If / Else Builder lets you add conditional logic to an importer without writing JavaScript. You describe a rule in plain terms (IF these conditions are true, THEN do this, ELSE IF …, ELSE …) and CSVbox converts it into a validation or a data transformation that runs on every imported file. Use it to:
  • Fill in or standardize values based on other columns (“If Country is US, set Currency to USD”)
  • Remove rows you don’t want imported (“If Email is empty, delete the row”)
  • Show users a clear error on the exact cell that is wrong (“If Age is less than 18, flag an error on Age”)
The builder is available in two features:

How to use it

1

Open the section

Go to the edit sheet page and open the Validation Functions or Data Transforms section.
2

Add or edit a function

Add a new function, or edit an existing one, and give it a name.
3

Switch to Visual mode

Switch the editor from Code to Visual.
4

Build your rule

Build your rule.
5

Save the function

Click Save.
Code mode remains available for anything the builder cannot express. See Visual vs. Code mode.

How a rule is structured

A rule is a list of branches, checked from top to bottom. Only the first branch whose conditions are true runs. The remaining branches are skipped.
  • A rule can have a maximum of 10 branches (IF + ELSE IFs + ELSE). A counter above the builder shows n / 10 branches.
  • Once an ELSE exists, both Add Else If and Add Else are disabled, because nothing can follow ELSE.
  • Branches other than the first can be removed with the × at the top-right of the branch. The first IF branch cannot be removed.
  • Every branch needs at least one action. Every IF / ELSE IF branch needs at least one condition. Removing the last condition or action simply leaves a fresh blank one.

Conditions

A condition compares a column to a value:
Click Add Condition to add more conditions to a branch. Extra conditions have an × to remove them.

Operators

Text comparisons and Match case

For equals, not equals, contains, does not contain, starts with, and ends with:
  • By default the comparison is not case-sensitive and leading/trailing spaces in the cell are ignored. " us ", "US", and "us" all equal us.
  • Tick Match case on a condition to compare exactly as typed, including capitalization and spaces.
  • The Match case checkbox only appears for these operators, because it has no effect on the others.

Number comparisons

For >, <, >=, and <=:
  • The cell and the value are both read as numbers.
  • Plain numbers (42, 3.5, -7) work as expected.
  • Text that does not start with a number (for example, n/a or $1,200) is not a number, so the condition is false.
  • Text that starts with digits is read up to the first non-numeric character (12abc is read as 12, 1,200 is read as 1).
If your data contains thousands separators or currency symbols, clean those values first with a Data Transform before comparing them as numbers.

Blank checks

is empty and is not empty ignore surrounding spaces, so a cell containing only spaces counts as empty. They do not need a value.
A comparison value cannot be left blank on the other operators. To test for blanks, use is empty or is not empty.

Combining conditions with AND / OR

When a branch has two or more conditions, choose how to combine them with the Match with dropdown: The choice applies to every condition in that branch. The dropdown appears once, before the second condition, and later separators just show the chosen word. You cannot mix AND and OR inside one branch. To express something like (A AND B) OR C, split it into two branches with the same action:

Actions

Actions are the THEN part of a branch. Click Add Action to perform several actions when a branch matches. Extra actions have an × to remove them.

In a Data Transform

  • Set requires a value. To blank a cell, use Clear instead.
  • Delete row removes the row regardless of any other actions in the same branch. It applies to Row rules only. See Scope.
  • If two actions in the same matching branch set the same column, the later one wins.

In a Validation Function

  • The error message is required and is shown exactly as you type it, so make it clear and actionable.
  • A branch can flag several columns at once by adding more actions.
  • Flagged cells are reported to the user during the review step so they can fix the data.

Scope: Row vs. Column

Each rule has a scope, chosen with the Row / Column selector next to the builder.
  • Delete row is only meaningful in Row scope. It does nothing in Column scope.
  • Switching scope after building a rule keeps your rule and just changes how it is applied.
  • If you are unsure, use Row.

How conditions read data

  • Conditions always look at the original values of the row, not values that earlier actions have set.
  • Within a single rule, a Set in one branch never affects the conditions of another branch. Because only one branch runs anyway, this rarely matters, but it does mean you cannot write “set A, then check A” in one rule.
  • To act on a changed value, create a second transform function. Functions run in sequence.

Example rules

Data Transform examples

Fill in a value when the cell is blank.

Validation Function examples

Flag a cell that fails a simple check.

Saving and error checking

  • Required fields are checked when you click Save. Anything missing is outlined in red with a message under that row, and the first problem is scrolled into view. After the first save attempt the checks update live as you type.
  • The rule is verified again on the server before it is stored. If something invalid gets through (for example, an unsupported combination), you see a message listing what is wrong.
  • Function names are required. The builder checks this at the same time.
  • In the list of functions, each visual rule is shown as a one-line summary, for example, IF Country == 'US' → Set Currency = 'USD'; ELSE → Set Currency = 'EUR'. Long summaries and long values are shortened with … (80 characters overall).

Visual vs. Code mode

Every function has a builder mode:
  • When you save a visual rule, CSVbox generates JavaScript from it automatically and stores both the visual definition and the generated code.
  • The generated code is marked with a comment: “Generated by the If/Then builder — edits here will be overwritten.”
  • If you need to customize the logic beyond the builder, copy the generated code into a new function in Code mode and keep it separate from the visual rule.
Changes made to the generated code are replaced the next time the visual rule is saved.

Best practices

  • Start with the most specific rule. Only the first matching branch runs, so order branches from narrowest to broadest.
  • Always consider an ELSE. It catches everything the other branches did not, which is useful for defaults and for flagging unexpected values.
  • Use a Validation Function for “should be” and a Data Transform for “make it”. Do not silently rewrite data that a user should correct themselves.
  • Keep each rule focused. Several small functions are easier to understand than one rule with ten branches.
  • Use clear error messages. Say what is wrong and what a valid value looks like.
  • Test with a small file containing a row for each branch, including edge cases (empty cells, extra spaces, different capitalization).

Troubleshooting