Preparing Your Import File
Everything the importer needs, and nothing it does not. Get the file right and the rest of the import is three clicks. The seven columns Download the sample from the Import CSV tab and you get...
Last updated
Everything the importer needs, and nothing it does not. Get the file right and the rest of the import is three clicks.
The seven columns
Download the sample from the Import CSV tab and you get exactly this shape:
location,floor_number,first_name,last_name,email,phone_number,occupant_type
101,1,John,Doe,john@example.com,5551234567,OWNER
102,1,Jane,Smith,jane@example.com,5555678901,TENANT
201,2,,,,,
| Column | Required | What to put in it |
|---|---|---|
location |
Yes | The location or suite number, exactly as you want it to read in URBI. Every row needs one. |
floor_number |
No | A number. Leave it blank rather than guessing. |
first_name |
No | The person's first name. Blank on a location only row. |
last_name |
No | The person's last name. Blank on a location only row. |
email |
No | Where their invitation goes. Without it the person cannot be created. |
phone_number |
No | Digits, with optional spaces, dashes, brackets, dots, a leading plus, or an x for an extension. |
occupant_type |
No | One of the six values in the next section. |
One row per person
A location with three people with the relevant role classifications is three rows, all carrying the same location number. URBI creates the location once and attaches all three people to it.
location,floor_number,first_name,last_name,email,phone_number,occupant_type
412,4,Dana,Wu,dana.wu@example.com,4035550142,OWNER
412,4,Sam,Ellis,sam.ellis@example.com,4035550188,TENANT
412,4,Ivy,Ellis,ivy.ellis@example.com,,TENANT
A location with nobody in it yet is one row with the location number filled in and the rest blank. It imports as a vacant location and you can add people later.
The six occupant types
Write them in capitals exactly as shown in the left column.
| Value in the file | What it means | What it does |
|---|---|---|
OWNER |
Off site person. Owns the location, lives elsewhere. | Creates the person, sets the location to Occupied. |
RESIDENT |
On site person. Owns the location and lives in it. | Creates the person, sets the location to Occupied. |
TENANT |
Renter. | Creates the person, sets the location to Rented. |
PROPERTY_MANAGER |
Manages the location for the person. | Creates the person, sets the location to Rented. |
DEPENDENT |
External contact, for example a family member. | Creates the person, sets the location to Occupied. |
EMERGENCY_CONTACT |
Someone to call in an emergency. | Creates no user and sends no email. Writes an Emergency Contact entry on the location's wiki instead. |
On a commercial or education property these same six values carry different labels in the interface (Employee, Student, Teacher and so on), but the values you write in the file never change.
How the occupant type sets the location's status
This catches people out, so it is worth stating plainly.
- Any row typed
TENANTorPROPERTY_MANAGERsets the location to Rented. - Any other filled in type sets the location to Occupied.
- A row with no occupant type leaves a brand new location Vacant.
When a location has several rows, a person always wins. If location 412 has a rental-classified row and a rental-classified row, the location ends up Rented no matter which order the rows appear in, and a later person row can never pull it back to Occupied. An person row only claims a location that is otherwise empty.
Column names you do not have to fix
URBI matches your headers to its own fields before you confirm anything, so an export from another system usually maps itself. Any of these are recognised:
| URBI field | Headers it recognises |
|---|---|
location |
location, location number, location no, location name, location id, suite, apt, apartment |
floor_number |
floor number, floor no, floor, level, storey |
first_name |
first name, firstname, first, fname, given name |
last_name |
last name, lastname, last, lname, surname, family name |
email |
email, email address, e mail, mail, email addr |
phone_number |
phone number, phone, mobile, cell, telephone, tel, cell phone, phone no |
occupant_type |
occupant type, occupant, type, role, person type, user type |
Anything it still cannot place, you set by hand on the mapping screen. Columns you leave unmapped are simply ignored, so you do not have to strip extra columns out of an export first.
Five things that will save you a round trip
- Save as CSV, not XLSX. The uploader reads CSV only.
- One header row, at the very top. Property management exports often carry four or five title rows above the real header. Delete them.
- Every row needs a location number. A row without one cannot be imported at all.
- No two rows with the same email and the same location. The second one is refused as a duplicate invite.
- Check the emails are the ones you want to write to. Nobody is emailed at import time, but these are the addresses that receive an invitation the moment you later press Bulk Invite, so they still need to be right.
What is not in this file
Leases, rent amounts, condo fees and parking are a separate import. This file creates locations and people only.