This is the ultimate template to get you up, running, and organized with all aspects of a commercial property management workflow. Whether you manage just a couple of units or many, this Commercial Property Management template has a dedicated space for everything: Buildings, units inside those buildings, tenants, tenants’ respective leases, vendors, and even service requests.

Everything is linked accordingly and contains key views at the table level to gain easy insights into important qualitative and quantitative information about your properties.

Let’s jump into the features of this expansive template. Here’s the rundown, by table:

Database

Buildings

Can’t have units without buildings, right? The Buildings table provides a high-level overview of each building’s properties, such as location, units and the occupation rate. This table also has views filtered by city so that you can easily toggle between buildings across different cities!

Fields

• Name. The building’s name.
• Image. A field for storing the building’s pictures.
• Address. The building’s address.
• City. The city the building is located in.
• State. The state the building is located in.
• Zip code. The zip code the building is located in.
• Units. This is a linked field to the Units table, which provides an overview of the units housed in the building.
• Tenants. This is a lookup field to the Units table, which provides an overview of the tenants located in the building.
• Rented units. This formula field filters the Units that have a active lease.
• Units count. This count field counts the number of units in the building.
• Rented units count. This formula field counts the Rented units field.
• Percentage occupied. This formula calculates the occupation rate based on the Units count and Rented units count fields.
• Service requests count. This count field counts the number of service requests made for the building.
• Contacts. This is a linked field to the Contacts table, identifying the points of contact used for the respective building.
• Contacts email. This formula field holds the email addresses of the contacts. This field is hidden by default since it is only used by the Application Builder.
• Occupation symbol. This formula field returns a colored dot. This field is hidden by default since it is only used by the Application Builder.

Views

• All buildings. Displays all buildings under management, sorted alphabetically by Name.
• All buildings grouped by city. Displays all buildings grouped by City, sorted alphabetically by Name.
• Buildings with occupation ≥ 66%. Displays all building with a Percentage occupied higher or equal to 66.
• Buildings with occupation between 33% and 66%. Displays all building with a Percentage occupied between 33 and 66. The upper and lower border is not included.
• Buildings with occupation ≤ 33%. Displays all building with a Percentage occupied lower or equal to 33.
• Chicago. Displays all buildings located in Chicago.
• New York City. Displays all buildings located in New York City.
• Los Angeles. Displays all buildings located in Los Angeles.
• Buildings. Displays all buildings in a gallery view, sorted alphabetically by Name.

Units

Now that we have buildings sorted out, let’s talk units. Every unit has a name and floor, but they also relate to buildings, leases, and service requests.

Fields

• Name. Each individual unit has a name. After all, no two units are the same, no matter how similar they might be.
• Building. This is a linked field to the Buildings table, which provides a simple way to put together each unit with its respective building that it belongs to.
• Floor. Whether it’s a garden unit, basement unit, or on a floor, one of the main features of units is the level it’s on.
• Service requests. This is also a linked field, but to the Service requests table.
• Open service requests. This formula field filters the service requests that are not marked as fixed yet.
• Open service requests count. This formula field counts the number of Open service requests.
• Leases. This is a linked field to the Leases table. This field contains all leases that were ever signed for a unit. Both the active leases and the ones that are already expired.
• Tenants. This lookup field to the Leases table shows the associated tenant for each lease.
• Active lease. This rollup field calculates if there is a lease on the unit that is currently active.
• Contacts email. This formula field holds the email addresses of the contacts. This field is hidden by default since it is only used by the application builder.
• Building name. This rollup field holds the building’s name. This field is hidden by default since it is only used to create a group by view.
• Tenants names. This formula field holds the contact’s name. This field is hidden by default since it is only used by the Application Builder.
• Active lease symbol. This formula field returns a colored dot that denotes whether the unit has an active lease or not. This field is hidden by default since it is only used by the Application Builder.

Views

• All units. All units, sorted alphabetically.
• All units grouped by building. Displays all units, grouped by the building and sorted alphabetically.
• All units grouped by building and floor. Displays all units, grouped by the building and the floor they are located, and sorted alphabetically.
• Units with active leases. Displays only the units that have an active lease.
• Units without active leases. Displays only the units that does not have an active lease.

Leases

A lease is what binds together the tenant and the unit, so it’s only natural that the ultimate Commercial Property Management template has a table dedicated to leases.

Fields

• ID. Each lease has a unique identifier, so jot it down here.
• Tenant. This is a linked field to the Tenants table. It allows you to easily view which tenant pertain to each specific lease.
• Unit. This is a linked field to the Units table. It shows the unit involved in the lease.
• Start date. The start date for the lease.
• End date. The end date for the lease.
• Scan/PDF. Regardless of whether the lease was signed digitally or physically, it’s easy to keep track of it with this field where you can store and reference it as needed.
• Notes. A notes field for any other broader information that may need to be captured for the lease.
• Pets allowed. This Boolean field denotes if the lease allows pets.
• Is active. This formula field returns a boolean to indicate if the lease if still active. This means that the current date is between the Start date and End date.
• Is active symbol. This formula field returns a colored dot that signifies whether the lease is active or not. This field is hidden by default since it is only used by the Application Builder.
• Building. This rollup field shows the name of the building. This field is hidden by default since it is only used to create a group by view.

Views

• All leases. There are no filters for this view, and it’s sorted in chronological by earliest lease start dates.
• All leases grouped by building. Shows all the leases grouped by the building they belong to.
• Active leases. Shows only leases that are not expired yet.
• Expiring this year. Shows only leases that are expiring in the current year.
• Office pets. Shows only leases that allow pets. Because office pets are awesome!

Tenants

The Tenants table consists of different pieces of information about the tenants. This table links the tenant to a lease and therefore indirectly to a unit.

Fields

• Brand. The name of your tenant.
• Industry. The industry in which the brand operates.
• Lease. This is a linked field to the Lease table for the lease agreement between the landlord and the tenant(s) for their respective units.
• Unit. This is a lookup field to the Lease table that shows the unit for the lease.
• Building. This is a lookup field to the Lease table that shows the building where the unit is located.
• Interested in renewal. A simple yes/no question to give you an idea of which tenants may be short-term, long-term, and/or how far in advance you should be looking to show units when the lease expires.

Views

• All tenants. All tenants, sorted alphabetically.
• Renewal . Displays only the tenants who are interested in renewing their lease.
• Retail. Displays only the tenants who are in the retail industry.
• By industry. Displays all tenants in a kanban view, stacked by Industry.

Service requests

Though it’s one of the least favorable aspects of property management for both landlords and tenants, service requests are a critical component of renting. This table has an Urgent service requests view which allows you to see only the most critical, time-sensitive requests based on the service request’s Priority.

Fields

• Issue. A short name/title for the issue at hand.
• Unit. This is a linked field to the Units table. It’s imperative to know which unit the service request relates to!
• Issue detail. A long text field for detailed information about the issue.
• Picture. A file field that allows uploading one or more pictures to clarify the issue.
• Date submitted. The date that the service request is submitted.
• Priority. Not all service requests are equal. After all, a gas leak should in theory be higher priority than a broken cabinet handle! This field allows you to designate service request priorities as such.
• Est. date of completion. The date the service request is expected to be completed.
• After-hours access. Some tenants may be more flexible (or cautious) about allowing vendors to enter the unit after hours. In this case, a simple checkbox allows you to determine if the tenant is okay with vendors to enter units during off-hours.
• Vendor responsible. This is a linked field to the Vendors table. Each service request is likely to be handled by a single vendor, though the field does allow for allocating more than one vendor to a single service request.
• Contact responsible. This is a linked field to the Contacts table. Each service request is assigned to a contact of the building. This contact is responsible for future follow-up on the issue.
• Fixed. A simple yes/no answer to determine if the service request has been fixed.
• Potential contacts. This formula field filters the contacts that belong to the building for the issue. This field is hidden by default since it is only used by the application builder.
• Priority symbol. This formula field returns a symbol based on the Priority. This field is hidden by default since it is only used by the application builder.
• Contact symbol. This formula field returns a coloured dot. A green dot means that a contact has been assigned. A red dot means that there is no contact assigned for this request. This field is hidden by default since it is only used by the Application Builder.
• Vendor symbol. This formula field returns a coloured dot. A green dot means that a vendor has been assigned. A red dot means that there is no vendor assigned for this request. This field is hidden by default since it is only used by the Application Builder.
• Fixed symbol. This formula field returns a coloured dot. A green dot means it is fixed, a red dot means that the request is still open. This field is hidden by default since it is only used by the Application Builder.

Views

• All service requests. Displays all service requests in chronological order from oldest to newest.
• Open service request. Displays only service requests that have not been Fixed yet.
• Urgent service requests. Displays only service requests with Priority tagged as urgent.
• New service request. Displays a form that you can share with your tenants in order to initiate a new maintenance request.
• By priority. Displays all service requests in a Kanban view, stacked by Priority.

Vendors

As a property manager, you likely have multiple vendors for specific services, such as heating, electrical, locksmithing, and more. This table is filled with all sorts of different properties to keep track of such vendors!

Fields

• Name. Some vendors may have DBAs (Doing Business As names), so it’s up to you to determine how you address each vendor.
• Specialty. Each vendor has something that they do best—whether it’s plumbing, electric, locksmithing, or something else.
• Service request URL. Many vendors have websites where customers are able to submit service requests online. Copy and paste those links here so that you don’t have to track them down every time. Instead, they’re just one click away!
• Service requests. This is a linked field to the Service requests table where you can see which service requests vendors are (or have been) responsible for.
• All requests fixed. This rollup field calculates if all the Service requests assigned to this vendor are already fixed.
• Point of contact. This field is designated for the primary point of contact for that vendor.
• Email. Use your email of choice—either the general company email, or the point of contact’s email address.
• Phone. Same as email, but for phone.
• Business card. It may seem a little old school, but many businesses still use business cards. Take a picture of it, upload it to this field, and save it forever digitally! Then, share a link to it so that it’s always accessible.
• Notes. An all-purpose notes field for whatever you deem may be important to note about your property management vendors.

Views

• All vendors. Displays all vendors, sorted by specialty for easy categorization.
• Vendors with open service requests. Displays only the vendors where All requests fixed is checked.

Contacts

Although resources are critical pieces to successfully managing property, you need points of contact to orchestrate necessary services for proper management of the buildings. This table identifies which contacts serve as mediums for important processes such as signing leases and linking service requests to the required vendors.

Fields

• Name. The contact’s name.
• Role. The contact’s role or title.
• Responsibilities. A brief description of the responsibilities that the contact has.
• Phone number. The contact’s phone number.
• Email. The contact’s email address.
• Password. This password field is by default set to template. This password field is used by the Application Builder.

Views

• All contacts. Displays all contacts sorted in alphabetical order.

Application: Service Requests Manager

Login

This page allows the user to identify themselves.

Events

• After login: the authenticated user is redirected to the Dashboard.

Dashboard

This page shows an overview of the buildings where the authenticated user is responsible for. It also shows an overview of the open service requests for those buildings.

Data sources

• My buildings. All Buildings of the authenticated user.
• Open service requests. All Service requests in one of the buildings of the authenticated user that have not been fixed.

Building details

This page shows the details of a single building. It also shows all associated units in a table element.

Data sources

• Building. A single building based on the ID.
• Units. All Units that are associated with the building.

Unit details

This page shows the details of a single unit. It also shows all associated leases and service requests in a table element.

Data sources

• Unit. A single unit based on the ID.
• Leases. All Leases that are associated with the unit.
• Service requests. All Service requests that are associated with the unit. This includes service requests that are already fixed.

Lease details

This page shows the details of a single lease. It shows a preview of the lease contract in the browser.

Data sources

• Lease. A single lease based on the id.

Service request details

This page shows the details of a single service request. It also offers the possibility to assign a contact and a vendor to fix the request

Data sources

• Service request. A single service request based on the ID.
• Contacts. All Contacts from the database.
• Vendors. All Vendors from the database.

Events

• On click:
  • Updates the fixed status in the Service requests table.
  • Redirects to the Dashboard page.

Assing contact

This page serves as the confirmation page to assign a contact to a service request.

Data sources

• Service request. A single service request based on the ID.
• Contact. A single contact based on the id.

Events

• On click:
  • Updates the contact in the Service requests table.
  • Shows a notification that the operation was successful.
  • Redirects to the Service request details page.

Assign vendor

Data sources

• Service request. A single service request based on the ID.
• Vendor. A single vendor based on the ID.

Events

• On click:
  • Updates the vendor in the Service requests table.
  • Shows a notification that the operation was successful.
  • Redirects to the Service request details page.