The review step shows the first few rows exactly as they will land, gives you two ways to test the file without touching your data, and then asks up to three questions. The questions only appear when they apply, and each one exists because the alternative is a mess that is expensive to undo.
“Before You Commit”
Two buttons sit at the top of the step. Neither one changes anything, so there is no reason not to use both.
- Check this file reads the whole file and scores it out of 100, then lists what it found: email addresses that will not send, dates it could not read, amounts with stray characters, rows that are nearly empty, two organizations whose names differ by a space, dates in the future, and text that arrived with broken accents. Each finding says how many rows it affects.
- Simulate import actually runs the import and then throws the result away. You get the real counts before you commit: how many records would be created, how many updated, how many skipped, how many would fail, and the reason for each failure. Files over 25,000 rows are sampled, and the report says so.
A simulation is the honest answer to “what will this do”, because it is the same code that does the real run. If the simulated numbers are not what you expected, go back to the mapping step. That is far cheaper than reverting.
“Import Quietly”
This box is ticked for you, and you should almost always leave it that way. Historical rows already happened: nobody needs a receipt for a gift from 2019, and a welcome email to eight thousand people you imported this morning cannot be recalled.
With it ticked, no notifications, emails or automations fire for anything the import creates. Untick it only when you are importing something happening now and you want the usual messages to go out.
“Names You May Already Have”
Two rows sharing an email address are not a risk. Studio matches people on email, so those collapse into one record on their own.
The risk is the case email cannot see: the same human under a different address. Morgan Carter at morgan@lighthouse.com in your file, when People already holds Morgan Carter at morgan@gmail.com, imports as a second Morgan Carter, and nothing downstream will ever connect the two.
So Studio groups the file, looks for people you already have, and sorts what it finds into three groups so you can spend your attention where it matters:
- Almost certainly the same person. The id from your old system matches. These are attached to the existing record unless you say otherwise.
- Probably the same person. The name matches and something else agrees: a phone number, an address, a postcode.
- Might be the same person. Only the name matches. Read these ones properly, because two different people really are called James Wilson.
For each group you choose:
- Same person writes the file's details onto the record you already have. No second copy.
- Different people brings the row in separately and stops asking.
You can set a whole group at once, and a donor with two hundred gifts is one decision rather than two hundred. Where more than one existing person shares the name, pick which one it is before choosing Same person.
“Person or Organization?”
Businesses, foundations and trusts give money, and they are not humans. Studio flags rows whose name reads like an organization and asks you to confirm each one, because guessing wrong in either direction is bad: a trust filed as a person gets addressed as “Dear Living”, and a person called Mr Church filed as an organization loses their first and last name.
You can also correct the organization name inline before confirming.
“These People Were Deleted”
Deleted people stay in the database so their giving and history survive. An import matches on email, so a file containing someone you deleted will bring them back.
They come back rewritten from the file rather than as they looked when deleted, so nothing stale rides along. But if you deleted them on purpose, take those rows out of your file before you run it. This warning lists exactly who, so you can check.
Reading the Preview Table
The table above these questions is the mapping applied to real rows from your file, not a generic sample. It is the cheapest check in the whole process:
- Are dates in the year you expect, rather than 1905 or 2025 when the file says 2026?
- Did a one-line address get split into street, city, state and zip?
- Are amounts in dollars rather than cents?
- Is anybody's entire name sitting in the first name column?
Anything wrong here is wrong in the import. Go back and fix the mapping. It is a great deal quicker than reverting.
Large Files
Past 25,000 rows the import runs in the background in chunks. You can leave the page and come back to it, and the progress bar picks up where it is.