Validate

Everything Sloose can tell you without writing anything, in one list.

Errors block, warnings do not

An error means the run cannot proceed: a required field with blank rows, a formula that does not compile, a match rule using a method your CRM’s search will reject.

A warning means Sloose thinks you may not have intended this. A field that will import empty on 40 rows. A row filter that holds back every row. Duplicate rows in the file. You can run anyway — warnings exist because “this is unusual” and “this is wrong” are different claims, and only you know which one applies.

Grouped by where you fix them

Problems are grouped by the step that fixes them, in step order, not by where they were detected. A picklist value that has no mapping is a Values problem even though it surfaced during validation, so that is where it is filed — with a link straight to it.

That grouping is the whole design of this step: the question you have when looking at a problem is “where do I go”, and the answer is on the page.

One-click resolutions

Some problems come with the fix attached. Unmapped picklist or lookup values carry a Leave n values blank button, which writes the explicit “blank” choice into the value map for each one.

That is a real decision, not a shortcut past the problem: you are saying these source values have no destination equivalent and the field should be empty for those rows. It is recorded in the value map like any other mapping, and it will still be there next time you load the project.

What it checks

Roughly in the order the steps come:

Data

• Duplicate rows within the file.
• A row filter that does not compile, or that holds back everything.
• A row filter that reads this row’s records — the file is filtered before any record exists, so the reference could never resolve. Use Only import when… on the Match step instead.

Match

• A match rule that is not filled in, on a module set to match.
• A match method the destination’s search does not support.
• A match rule reading rec.* — those records do not exist when the check runs.
• Gates and update guards that do not compile, or that reference a module not in this import, or one written later in the row than the module using it.

Map fields

• Required fields with blank rows, listing which rows.
• Formulas that do not compile.
• Fields mapped from a column that is blank in every row.
• Percentages that are still fractions. A spreadsheet stores 15% as 0.15 and shows you 15%, so a percentage column out of Excel — or a CSV somebody made in Excel — is a hundred times too small, and every other check passes it, because 0.15 is a perfectly good number for a percentage field. It just means 0.15%. Sloose says so when every value in the column is below 1, and offers Multiply by 100, which maps the field through a formula. Your file is not touched.

Values

• Unmapped picklist values, and picklist values produced by a formula that are not valid options.
• Unmapped lookup values, with the suggestion to switch the field to search mode instead.
• Fields that will import empty because their source value is mapped to blank — with the row count, so “40 of 500” reads differently from “40 of 41”.

Fixing a value versus fixing the mapping

Worth separating, because they solve different problems.

Fix the value when the file is wrong: a typo, a stray space, a number stored as text in three rows. Edit it in the grid on the Data step. The edit belongs to this job and does not touch your file.

Fix the mapping when the file is right and Sloose’s reading of it is wrong: the column is fine, it just needs a formula to trim it, or the field should have been a different one. Fix it once on the Map step and every row is fixed.

If you find yourself editing the same problem in twenty rows, that is the file telling you it is a mapping problem.

Asking the AI

Where AI is configured, Explain takes the problems in front of you and describes them in your org’s own vocabulary, proposing a fix where one can be applied.

It proposes; you accept. Nothing is applied on the model’s say-so — see Your data and the model for what is sent.

Excluding rows instead

If a handful of rows are beyond saving, exclude them on the Data step rather than bending the mapping around them. They stay in the file, out of this run, and visible — which is easier to explain later than a formula written to work around six bad rows.