AI mapping that fixes the values, not just the columns

How AI data mapping works

One button, Draft everything, proposes the whole import. Every proposal waits for you.

1. 1
   Names first, for free

   Sloose matches columns to fields by name, spelling and values. This part uses no AI and no credits.

2. 2
   Then the AI reads your data

   It reads your column names and sample values, and proposes a field for each column it can place.

3. 3
   A formula where the values need work

   Where a column needs a different case, a split or a join to fit its field, the proposal comes with a formula. It also translates the values of each picklist it maps.

4. 4
   Checked against your CRM

   Every field it proposes is checked against your CRM's real fields before you see it, so it cannot invent one. Every picklist option it names is checked against the field's real options.

5. 5
   You decide

   Each proposal shows the values it would produce from your rows. Use it, change it or turn it down. Nothing is used until you press a button.

Split full name into first and last name

Contact lists rarely agree on how to write a name. This file has surnames in capitals, a name all in lower case, titles, and a Spanish double surname.

A formula is one rule per field, written in JavaScript like a spreadsheet formula. This pair handles names written Last, First:

First name

helpers.proper(helpers.split(row.Name, ',', 1))

Last name

helpers.proper(helpers.split(row.Name, ',', 0))

The outputs show it is right for two rows of seven. The other five have no comma, so their first name comes out empty. You see that before the run, beside each row, not after the import in your CRM.

row.Name.includes(',')
  ? helpers.proper(helpers.split(row.Name, ',', 1))
  : helpers.proper(row.Name.replace(/^(Mr|Mrs|Ms|Dr)\.?\s+/i, '').split(' ')[0])

row.Name.includes(',')
  ? helpers.proper(helpers.split(row.Name, ',', 0))
  : helpers.proper(row.Name.replace(/^(Mr|Mrs|Ms|Dr)\.?\s+/i, '').split(' ').slice(1).join(' '))

Excel address in one cell to multiple columns

Sloose has no built-in address parser, and it does not pretend to. Addresses go the same way as names: a formula for each address field, built from helpers such as split and join. The outputs show each row's result, so an address written another way is visible before the run. In the file above, the German address puts the postcode before the city, and the Bristol address runs across three lines in one cell.

Ask the AI in the formula editor to write or change a rule in words, or write it yourself.The expressions reference lists every helper.

Import date format: dd/mm or mm/dd?

Nothing can tell from 03/04/2026 alone whether it means 3 April or 4 March. Sloose does not guess. It reads each date the way you say, and shows you the result for every row.

• From an Excel file, a cell stored as a date arrives as 2026-03-04, which can only mean one thing.
• From text, an administrator sets the organisation's date order once: day/month/year, month/day/year or year/month/day. A date such as 2026-03-04 is read as written.
• From a file that mixes countries, a formula can read each row's country and choose the order for that row.

Registered

helpers.date(row.Registered,
  row.Country === 'United States' ? 'MM/DD/YYYY'
  : row.Country === 'Japan' ? 'YYYY/MM/DD'
  : 'DD/MM/YYYY')

What the formula makes of each row

Country	Written	Becomes
Australia	04/03/2026	2026-03-04
United States	03/04/2026	2026-03-04
Germany	04.03.2026	2026-03-04
United Kingdom	4 Mar 2026	4 Mar 2026 (not read)
New Zealand	2026-03-04	2026-03-04
United States	46085	46085 (not read)
Japan	2026/03/04	2026-03-04
Ireland	04/03/26	2026-03-04

Six rows become 4 March 2026. Two cannot be read as a date: 4 Mar 2026 and the Excel serial number 46085 stay as written. Validate lists every row where a date field would get a value that is not a real date, so you fix those two cells before the run.

Validate passes a date that is real in either order, such as 03/04/2026, because it cannot know which order a file used. That is why the order is your decision.

Picklist values that don't match your CRM

"N.S.W.", "new south wales" and "Tassie". "Calif." and "CA". "google", "Adwords" and "Google Ads". A value that is not one of the picklist's options can fail the row, or be kept as typed where reports and filters built on the field's options miss it. Sloose translates the values before the import runs.

Free matching first

Translate values lists every distinct value for each picklist field, with how many rows hold it. The free matcher offers the option for a value that differs from it only in case, spacing, punctuation or accents, so "new south wales" is offered as "New South Wales" without the AI. Words such as "N/A" and "TBA" are offered as blank.

Then the AI, for what spelling cannot reach

No amount of spelling gets from "Tassie" to "Tasmania" or from "Calif." to "California". The AI reads what the values mean. Every option it names is checked against the field's real options before you see it, so it cannot propose a value your CRM would refuse. Answers it is sure of can be used in one click; the rest are offered as choices, best first.

Your decision, kept

You can also leave a value blank on purpose. A value nobody has mapped stops the run at Validate, rather than failing rows in your CRM. Value maps are saved with a template, so "Calif. is California" is a decision you make once.

Phone numbers with and without a country code

The same contact list has numbers written with +61, without it, with brackets and with spaces.

row.Phone.trim().startsWith('+')
  ? '+' + helpers.digits(row.Phone)
  : ['AU', 'Australia'].includes(row.Country)
    ? '+61' + helpers.digits(row.Phone).replace(/^0/, '')
    : ['UK', 'United Kingdom'].includes(row.Country)
      ? '+44' + helpers.digits(row.Phone).replace(/^0/, '')
      : row.Phone

Mapping without the AI

What the AI sees, and what it costs

Related