Map fields

Each destination field gets its value from one of five places.

The five modes

Mode	Takes	Use it for
Column	A column from your file, as-is.	Most fields.
Static	A fixed value, the same on every row.	A source tag, a fixed owner, a campaign name.
Formula	An expression.	Combining columns, cleaning values, conditionals.
Search	A live lookup against another module.	Pointing at a record by a value rather than an id.
Skip	Nothing.	Deliberately leaving a field alone.

Skip is worth using on purpose. A field explicitly skipped reads differently from a field nobody got to, both to you next month and to whoever loads the project after you.

Auto-map

Makes the first pass and stops. It is deliberately conservative — a wrong mapping that looks right costs more than an obvious gap — so expect it to leave work for you.

Every proposal says where it came from, which is the part worth reading:

Provenance	Means
your org calls it this	An administrator recorded that your files use that name for this field. This is knowledge, not a guess.
a name match	The column and the field are called roughly the same thing. Usually right, occasionally not.
an org default	The module carries a seed mapping for this field.
AI	A model proposed it, with a confidence and a reason.

A proposal from an org alias is applied cleanly. Anything else that lands on a required and unique field is flagged for you to check rather than applied quietly — because a wrong value in a matching key is not recoverable by re-running.

Auto-map also tells you when a column it mapped is blank in every row. The mapping is valid; it just writes nothing.

Asking the AI

Where AI is configured, the AI proposal goes further than name matching, using sample values to break ties. Two things hold about it:

• Every proposal is validated against your org’s real fields before you see it. The model cannot invent a field. One that fails validation is downgraded or dropped rather than shown.
• It proposes; you accept. Nothing is saved on the model’s say-so.

See Your data and the model for what gets sent.

Reading the grid

Fields are grouped by section, with their type and any flags:

• REQ — required. The step will not let you leave with it unmapped.
• AUTO — currently mapped by auto-map.
• The type badge — TXT, PICK, DATE, LOOKUP and so on — which decides what the field will accept and whether it needs a value map.

The filter chips across the top narrow to Required, Unmapped or Mapped, and the search box finds a field by name. On a module with 200 fields, Unmapped is the view you want.

Where your columns go

The grid is field-first — every field in the module, whether or not anything fills it. The Data Preview on the right is the other direction: your file, with each column marked by what the import does with it.

The colour is the module. A column several modules read gets a band of each of their colours rather than one neutral one, so “who uses this” survives being shared.

The mark under the name says how far it gets:

• A solid underline: the column reaches your CRM.
• A dashed underline: it only decides something — it is read, but never written.

The glyphs beside the name say which job, and a column can do several:

	Job
→	Written to a field.
ƒ	Read by a formula.
⌕	Used to find a linked record (search mode).
⌖	Used by the match rule to identify the record.
≋	Used by a gate or an update guard, deciding which rows import.

This is why a column feeding only a formula still counts as used: helpers.num(row["Annual Revenue"]) consumes that column as surely as a direct mapping does.

Click a column heading for everything about it in one card: how many distinct values it holds, how many are blank, and every job it does — with the field it lands in, and whether that field’s values are translated on the Values step.

Columns nothing reads

The header counts them: N unused. Click it to show only those columns, and click again for the whole file.

Unused is not an error. Files arrive from wherever they arrive from, usually carrying far more than this import needs, and there is nothing to tidy up — Sloose ignores a column nobody mapped. The count is there so that forgetting one looks different from not needing it.

Fields you will not see

Two kinds are hidden:

• Fields the import authors itself — record ids, the links Sloose writes between modules.
• Fields your administrator excluded — system fields nobody should map, set per module or org-wide. See Curating modules.

If a field you expect is missing, it is one of those, or discovery has not run since it was added.

One column, several fields

Nothing stops you mapping the same column into several fields — a name column feeding both a display name and a search key is ordinary.

The other direction, several columns into one field, is a formula:

`${row["First Name"]} ${row["Last Name"]}`.trim()

Search mode

Instead of mapping a lookup by id, search for the record at run time:

Find the Account where Account Number equals this row’s Account No

Use it when your file names the related record rather than identifying it, and when there are too many possible values to keep in a value map. The alternative — mapping the values explicitly — is on the Values step, and is the better choice when the set is small and stable.

Formulas

The f(x) button on any field opens the formula editor, which runs your expression against real rows from your file as you type, so you see what it produces before you leave the step.

Full reference: Expressions.