The Pre Import Checklist

Work through this once before you import a building. It takes about ten minutes and it is the difference between a clean onboarding and a week of apologising to residents.

Part 1: Is the building ready to hear from you?

The import sends invitation emails immediately and they cannot be recalled. Before anything else, answer these.

If you want to see the mechanics without contacting anybody, import a handful of unit only rows (unit numbers, everything else blank). No emails are sent and you can delete those units afterwards.

Part 2: Is the property set up?

• The property exists in URBI and you are on the right one. There is no way to move an import between properties afterwards.
• The property type is right (residential, commercial or education). It decides what the occupant types are called everywhere in the interface.
• Any units already in URBI are the ones you expect. An import adds to what is there, it does not replace it.

Part 3: Is the file right?

• Saved as CSV, not XLSX.
• Exactly one header row, at the very top. Delete the report title rows that property management exports put above it.
• 2000 rows or fewer. Split a larger building into two files.
• Every row has a unit number.
• Unit numbers are written the way you want to see them in URBI, and consistently. 101 and 0101 create two different units.
• One row per person, all rows for a unit carrying the same unit number.
• occupant_type is one of the six accepted values, in capitals.
• No two rows share the same email address on the same unit.

Part 4: Are the emails right?

This is the part worth slowing down for, because an email address is the one field that reaches a real person.

• Every address belongs to the person on that row. A shared family address on two rows means only the first person can be invited.
• No placeholder addresses (noemail@, none@none.com, a manager's own address standing in for a resident). They create real accounts for people who are not there.
• Addresses with obvious typos in the domain are corrected first. URBI checks that an address is well formed, not that it exists, so a typo becomes an invitation that silently goes nowhere.
• Anyone you are not ready to contact yet is left out of this file. Adding them later is easy, un inviting them is not.

Part 5: The dry run

1. Upload the file and go as far as the Review step. Nothing is created and nothing is sent up to this point.
2. Read the Need Review panel in full. Those rows import as they are if you do not act on them.
3. Check the Unfixable count is zero, or that you have skipped those rows deliberately.
4. Compare the row count on the confirmation screen against the unit count you expect. A number well over your unit count usually means the file has extra header rows or blank rows in it.
5. Only now, press Import.

Part 6: Straight after the import

• Watch for the Unit Import Report email and read it against the file you sent.
• Open the Units list and spot check a few units for the right status (Owner, Rented, Vacant).
• Expect a few residents to reply. The most common questions are "is this real" and "I did not get it", and the answer to the second is usually a spam folder.

The five mistakes that actually happen

1. Importing into the wrong property. Check the property name at the top of the page before you upload.
2. Importing a test file into a live building. Real invitations went to real residents.
3. Leaving the extra header rows in an export, so row one becomes a unit called "Owner Register as of".
4. Ignoring the Need Review panel, then finding the occupant types were wrong and half the building shows as Rented.
5. Importing before the client has told residents, which turns a welcome email into a support call.

Next

• What Happens When You Import
• Import Errors and What They Mean