A Data Model for a Leasing Office

Most of us are familiar with the apartment rental process. But what does it take to run a leasing office? In this article, we look at a data model designed to do just that.

Earlier, we explained a data model for a website that lists residential rental units like apartments. In many countries, apartments are managed by a leasing company. This company handles the entire rental experience, from processing the initial renter application to performing maintenance work on the property.

In this article, we’ll explain the fundamental requirements of a leasing company. We’ll also examine a suitable data model that caters to those requirements.

What Should We Know About Leasing Companies?

Before we start the data model, let’s consider what a leasing company does:

• The leasing company maintains a list of all the units they manage. This list includes currently available units and units that will become available in the future (along with their availability dates).
• Prospective renters submit applications to the leasing company. Applications can be submitted online or at the leasing office. A system should capture all required details from prospective renters.
• Each application goes through a verification process. This verification process generally includes background and credit checks. Applications can be accepted or rejected based on the outcome of this process. At end of the process (if it is successful), a unit is offered to the person.
• Once the application is approved, a unit is reserved for the person.
• The leasing office maintains records of rents paid by renters.
• Renters can request maintenance work for their units.
• These “service requests” are tracked and processed by the leasing office.

Looking at the above requirements, we can easily derive our main entities: properties and units, applications, renters, service requests, and staff. We can further divide the whole system into three categories, or subject areas, by grouping these entities based on their function.

The Leasing Office Data Model

As you can see, I’ve divided this model into three subject areas:

• Property Management
• Application and Lease Management
• Renter and Service Management

We will look at each of these subject areas individually, starting with Property Management.

Property Management

This subject area is all about keeping records related to units (properties) and leases. Usually, leases are offered for a set term of 12 months, 6 months, or 3 months. Some properties allow month-to-month leases. Rent prices can vary with the length of a lease; a longer lease may have lower monthly rent costs.

The unit table stores details about individual units. The columns in this table are:

• id – Each unit is assigned a unique internal ID number.
• unit_type_id – The type of unit, i.e. an apartment, a flat, a condo, or some other type of unit.
• community_id – Refers to the community table and details where the unit is located within a multi-building complex.
• address_id – Refers to the address table and signifies postal address of the unit.
• number_of_bedroom – The number of bedrooms in an apartment.
• number_of_bathroom – The number of bathrooms in an apartment.
• number_of_balcony – The number of balconies in an apartment.
• is_available – This column holds a ‘Y’ if the apartment is available and an ‘N’ if it is occupied.
• is_reserved –When this column is ‘Y’, the next occupancy of an apartment is reserved. Otherwise, it is NULL.
• unit_available_from – The date when an apartment becomes available for occupancy. This column will be populated only if the is_available column is set to ‘Y’.
• leasing_info_id –References the leasing_info table and contains leasing details about the apartment.
• unit_description – Describes details of an apartment in text format.
• carpet_area – The carpeted area of an apartment, in square meters
• unit_number – The unit’s number in the building.
• unit_at_floor – The floor where an apartment is located.

The community table holds the details about the communities where units are located. A community can have any number of units. The columns in this table are:

• id – The primary key of this table.
• community_name – The name of the community.
• address_id – Refers to the address table and signifies the physical address of the community.

The address table stores the street address for units. There can be multiple units located at the same address. Therefore, a separate table is created to hold these details. The “id” column is this table’s primary key; street_address holds the building number or name and the street name; city, state, and country are all self-explanatory, and zip holds the postal code.

The leasing_info table holds all possible combinations of leasing information. For example, all two-bedroom, two-bathroom apartments in a community may have the same rental value. The columns in this table are:

• id – The primary key of this table.
• leasing_type – Whether this is a personal lease or corporate lease. Some leasing offices (per agreement) will give the employees of certain companies discounted rates. We call this type of lease a corporate lease because of the agreement between the company and the leasing office.
• is_sub_leasing_allowed – Some leasing companies allow current renters to sublease their apartment. For example, a renter may have to move for a job before the lease is done. In that case, the renter may sublease their unit to another person for the remainder of the lease.
• application_fee – How much a potential renter pays to apply for an apartment. This fee may differ based on apartment size, i.e. $25 for a one-bedroom unit, $50 for a two-bedroom unit.
• security_deposit – The amount a renter has to pay upfront as security before occupying an apartment. Usually it is equivalent to 1-3 months’ rent.
• is_lease_termination_allowed – If a lease can be terminated before it expires. Many rental companies do not allow their renters to terminate their lease without a valid reason.
• lease_termination_cost – If lease termination is allowed, this column holds the fee for terminating a lease.

The following columns store the rental value of an apartment for different lease tenures:

• monthly_rent_1month_lease – The monthly rent on a month-to-month lease.
• monthly_rent_6months_lease – The monthly rent on a six-month lease.
• monthly_rent_12months_lease – The monthly rent on a twelve-month lease.

Application and Lease Management

This subject area revolves around renters and applications.

The renter table stores basic details about all rental applicants. Obviously, some (but not all) applicants turn into renters when their applications are approved and they move in. The columns in this table are:

• id – A unique number given to each applicant, which also serves as the primary key of the table.
• first_name – The first name of the applicant.
• last_name – The last name of the applicant.
• identity_proof_document – The name of the document submitted as proof of the applicant’s identity, e.g. a state ID, driver’s license, passport, etc.
• identity_proof_doc_id – The ID number on the document. Since an ID can be alphanumeric, this column is VARCHAR .
• permanent_address – The permanent address of an application.

This table can be further extended to hold other details like employer or family details. Just add more columns as needed.

The application table is the most important table in this subject area. It holds details about individual applications. The columns in this table are:

• id – Each application is given a unique number.
• renter_id – The prospective renter who submits the application.
• requirement – The type of unit the applicant wants, such as a one-bedroom executive apartment. This is a free text column that does not derive any functionality in the system, so I’ve made it optional. It is up to the leasing employee to fill in this field as needed.
• submit_date – When the application is submitted.
• processing_date – When the application is processed.
• processing_status – The application’s current status, i.e. processing, approved, or rejected.
• unit_id – The unit number for which the application is submitted. If the applicant does not choose an apartment when submitting the application, this column will be blank. It is nullable.
• unit_reservation_fee – The amount an applicant pays to keep the unit open until their application is processed. This amount is later adjusted in the first month’s rent. This fee is forfeit if the application is approved but the applicants do not move in. This fee is optional in many places, so I’ve made this column nullable.
• staff_id – The ID number of the leasing office employee who processed the application.

The unit_leasing_info table transforms an applicant into renter ˘ and maps the application with a unit. This table gets a record only after the application is approved. The columns in this table are:

• id – The primary key of this table.
• application_id – The unique application ID number.
• unit_id – The unit being leased. You must be wondering why we’re seeing this column again in this table. An applicant may change their choice of unit between the time they submit an application and are approved. Usually, the leasing office allows such a change at no extra cost if the new unit is available. But 95% of the time this column will have the same value as its counterpart in the application table.
• lease_tenure_in_months – How long the lease lasts, in months.
• monthly_rent – This is the amount paid by the renter each month.
• discount_in_rent – Leasing offices often use promotional offers to attract new renters. If such an offer is applied to a lease, this column holds the value of the discount in local currency.
• lease_starting_from – When the lease starts. Usually, this is the date when the renter is allowed to move into the apartment.
• lease_ending_on – The last day a lease is active.

Renter and Service Management

This subject area will manage any additional services performed by a leasing office, such as rent collection and maintenance services.

The staff table keeps records of all employees working for a leasing company. The columns in this table are:

• id – The primary key of this table. It assigns a unique ID number to each staff member.
• first_name – The employee’s first name.
• last_name – The employee’s last name.
• staff_role – The role of the employee, i.e. leasing officer, maintenance support person, cashier.
• employment_start_date –When the employee started working for the leasing office.
• employment_end_date – This nullable column populates only when an employee leaves the leasing company.

The rent_payment_log table tracks payments made by renters towards their rent. The columns in this table are:

• id – The primary key of this table.
• unit_leasing_log_id – We derive renter and unit details using this column.
• amount_paid – How much the renter has paid. Some leasing companies may accept partial rent payments.
• payment_date – The payment date.
• payment_medium – How a payment is made, i.e online, cheque, or cash.

The next three columns are nullable and are populated based on payment method:

• cheque_number – This column will be populated if payment is made by cheque.
• online_transaction_number – The online transaction number if the payment is made online.
• payment_accepted_by –The ID of the leasing office cashier that collected a cash payment.

The service_request table records service requests submitted by renters. The columns in this table are:

• id – The primary key of this table. It provides a unique number for each service request. This number can be included in all communications regarding that service request.
• unit_leasing_log_id – The unit for which service is requested.
• service_category_id – Service requests can be categorized based on their type, i.e. plumbing repair, ac/ heater repair, appliance repair, payment issue, etc. Requests are assigned to staff based on the nature of the service requested.
• problem_description – Details of the service requested by the renter, in free text format.
• log_date – When the service request was received by the office.
• sr_assigned_to – The ID of the employee assigned to the request.
• closure_date – The date when the service request is closed.

What Do You Think?

As stated at the beginning of this article, we’ve only covered the fundamental capabilities a leasing company would need. Many more functionalities could be added to this data model. For example, I can think of rental inquiry management and maintenance inventory tracking. What would we need to do to add these? And what features would you add to this model? Let us know in the comment section!