Import Errors and What They Mean
Every message the importer can show you, what caused it, and what to do. Messages appear in two places: on the Review step before you import, and in the Unit Import Report email afterwards. Read this...
Last updated
Every message the importer can show you, what caused it, and what to do. Messages appear in two places: on the Review step before you import, and in the Unit Import Report email afterwards.
Read this first: three rules
- Nothing is created until you press Import. Uploading, mapping and reviewing never touch your property. Anything that goes wrong in those steps leaves URBI exactly as it was.
- A warning does not stop a row. Warnings on the Review step import as they are unless you edit or skip them. Only an error stops a row.
- A row that fails does not stop the rest. The importer works through every row and reports each one separately.
Part 1: On the Review step
Errors, which stop the row
Unit number is required
What it means. The row has no unit number, so there is nothing to attach it to.
What to do. Type the unit number into the row, or skip the row. If many rows show this, your file probably has extra title rows above the header, or the unit column mapped to the wrong field on the previous step. Go Back and check the mapping.
Invalid email format: "..."
What it means. The address is not a well formed email. A trailing dot, a missing @, two addresses squeezed into one cell, or a stray space.
What to do. Correct it in the row, or clear the email entirely (the unit still imports, the person is skipped), or skip the row. URBI only checks the shape of the address, never whether the mailbox exists, so a well formed typo passes this check and becomes an invitation that goes nowhere.
Warnings, which import as they are
Email missing, will import unit only, skip resident
What it means. There is a name on the row but no address to invite them at.
What to do. Add the address if you have it. If you do not, leave it: the unit is created correctly and you add the person later, once you have their email.
Missing first name and last name, needed for resident creation
What it means. There is an email address but the name is incomplete. Both halves are needed to create a person.
What to do. Fill in the missing half. Left as it is, the unit imports and the person is not created.
"..." is not a valid type
What it means. The occupant_type is not one of the six URBI accepts. Exports commonly say "Owner Occupant", "Absentee", "Renter" or "Lessee", none of which URBI knows.
What to do. Change it to OWNER, RESIDENT, TENANT, PROPERTY_MANAGER, DEPENDENT or EMERGENCY_CONTACT. Left as it is, the row still imports and the unit is treated as owner occupied, which is often not what you meant.
Duplicate: same email and unit as row N
What it means. Two rows put the same person on the same unit.
What to do. Delete or skip one of them. Left in, the second row is refused at import time and reported as an existing invite. Note that the same address on two different units is fine, which is the normal case for an owner of two units.
Phone contains invalid characters: "..."
What it means. The phone has something in it that is not a digit, a plus, a dash, a space, brackets, a dot or an x. Usually a note that ended up in the phone column.
What to do. Clean it, or clear the cell. Left in, it imports as written.
Informational notes, which are usually fine
Unit "X" already exists, will add resident to existing unit
The unit is already in URBI. The person on this row is attached to the existing unit rather than a second one being created. This is normal when you are topping up a building that was imported before. It is a problem only if you did not expect the unit to be there, which usually means the unit numbers are formatted differently from last time.
User "..." already exists in URBI, will be linked to unit
That address already has an URBI account, from this property or another. They are given access to this unit rather than being sent a new invitation.
Part 2: In the Unit Import Report
Every row appears in the report with one of three labels.
Success messages
- Unit "X" created successfully. A new empty unit, from a unit only row.
- Unit created, resident name@example.com invited/added. The unit was created and the person was invited.
- Emergency contact saved to unit wiki for "X". The contact is on the unit's wiki. No account was created and no email was sent, which is correct.
Warning messages
- Unit "X" already existed. The unit was already in URBI so nothing was created. Harmless.
- Unit existed, resident name@example.com invited/added. The unit was already there, the person is new and was invited.
- Invite already exists for name@example.com in unit X. This person was already invited to this unit. No second email was sent and their original link still works. This is what you want to see when you re run a file.
- User name@example.com already assigned to unit X. They already have access. Nothing changed.
Error messages
- Failed to create unit: ... The unit could not be created, so nothing else on the row happened either. The text after the colon is the underlying reason. Most often the unit number is longer than the field allows or contains something unexpected. Fix that row and import it on its own.
- Unit created, but failed to invite name@example.com: ... The unit is there, the person is not. Fix whatever the message names and re import just that row, or add the person by hand from the unit. Re importing is safe.
- Unexpected error: ... Something outside the usual paths. The unit may or may not have been created, so open the unit before you retry. If it repeats on the same row, send the report line to support.
Part 3: Problems before you get that far
Failed to parse CSV file
The file is not readable as CSV. It is usually an XLSX renamed to .csv. Open it in Excel or Numbers and use Save As or Export to produce a real CSV.
Too many rows. Maximum 2000 rows per import
Split the file. Two imports of the same building are perfectly safe, and anyone invited by the first file is not emailed twice by the second.
Missing required fields: property_id, rows
The upload reached URBI with nothing usable in it, which normally means every row was skipped on the Review step. Go back and check that at least one row is still selected.
Nothing happens when I choose Continue
Check that a column is mapped to unit. Without it, no row can be built.
The report never arrived
The report goes to the address on the account that ran the import. Check the spam folder first. The import itself still ran: open the Units list to see the result.
Part 4: After the fact
I imported into the wrong property
There is no move. Delete the units from the wrong property one at a time, then import into the right one. Anybody who received an invitation has to be told, because their link is real.
I imported a test file into a live building
Delete the test units and remove the people. Invitations already delivered cannot be recalled, so tell whoever received them.
Half the building shows as Rented and it should not
The occupant types were wrong. TENANT and PROPERTY_MANAGER both set a unit to Rented, and a tenant row always wins over an owner row on the same unit. Fix the status on each unit from the Units list. Re importing with corrected types does not fix it: an owner row never pulls a rented unit back.
Somebody says they got two emails
They did not get two from the importer, which only emails an invitation once per person per unit. Two emails means either two different units on the same property, or somebody used Resend Invite, which re delivers the same link.