Best Practices for Tracking Custom Data for Community Associations

When your team gathers information about the communities you mention, homeowners, or even vendors, where does that data go? Not in a figurative sense, but literally. Do they jot it down on a post it? Does it go into an Excel spreadsheet, or get printed out and stuck to the wall on a sheet that nobody will look at again?

Or maybe you just ask Sue. You know, Sue (though she may go by another name in your office) the office historian-slash-encyclopedia. Want to know what percentage of the ownership is over 55? Sue knows. Need an account number for an obscure community? Sue knows. When does the FHA approval expire for this community? Just ask Sue.

But what will you do when Sue retires?


In a minute, I will share with you the ultimate list of sample custom fields drawn from real management professionals and what they are actively tracking (even the unusual ones!). But first, I want to share with you some best practices for setting up, tracking, and reporting on custom data. Ready to get started?

Every business has a wealth of odd information that isn't needed every day, but needs to be kept somewhere so you have it when you need it.

Chances are you are going to need to know some of this info in odd moments, like while you are meeting with a vendor, or cruising the community, or in a board meeting. You won't always have your folder/notes/Sue at your fingertips, but you do have your management software!

Tracking custom data consolidates your information, and helps to prevent errors due to outdated or inaccessible data. Custom fields also help your workflows by making it easier for you to evaluate, categorize, report on, and customize communications.

Best Practices for Custom Data Field Setup from TOPS Software

Planning Stage (What fields should you create?)

There are two criteria you should consider when deciding whether to track a custom field:

  1. If you need to write it down, you should be tracking it

  2. If it will ever be communicated to a resident, you need to be tracking it

Obviously you don't want to have wrong information just because the office historian is out that day, or you simply cannot remember some obscure detail. But choosing which fields to track is also a form of automation.

Say you write the welcome letters for a master community with 6 sub-associations, and you add a paragraph in the letter templates that says trash pickup day is Thursdays. Then, down the road you renegotiate the terms of the contract and now trash day is Wednesdays. Under your current system, you would have to edit 7 letter templates to insure that all of the letters reflect the new trash day. But if you are tracking that as a custom field, all you have to do is update the value in the community once and all of the letter templates will automatically fill that in from the custom field's code.

To create your custom fields, you will need to make a few decisions: where they will go, what you will name them, and what type of data is allowed.

Organizing Custom Fields (Where will they go?)

Organization is critical when setting up custom data fields. First, you need to insure that the layout and positioning of the fields make sense to your users to increase adoption. Having custom fields in your system is only successful if your team is entering the information into them. Organization of custom fields falls into two areas, ownership and grouping.

  • Ownership refers to where this information rightfully belongs, or which part of your software owns it. For example, if the documents say that 2 parking spaces are assigned to each property, that custom field needs to be stored on the property, where you only have to enter it one time, as opposed to storing it on the resident record, meaning you would have to enter the parking spaces on every resident's record, introducing redundancy and possible mistakes.
  • Grouping is how you physically organize the fields. Fields that are related to each other should be grouped together so that they are easier for your users to find. For example, lets say you have a community with mixed floor plans (Bed/Bath, etc.) You might want to create a series of custom fields to track that information, and group those fields together along with other fields that are specific to the property layout.

Naming Conventions (What will they be called?)

No matter how obvious a field name is to you, chances are someone is going to be confused by it. That's why it's important that you put some thought into the label you use when you create custom fields. Because the name tells the user what you expect to see in that field, it needs to be clear and informative. Because the label will appear on reports, it needs to be short and easily distinguished from other fields. To make it even more challenging, your field name needs to be unique from all the other fields in your system.

Data Types (What kind of data is allowed here?)

The last thing you need to really think about while you are planning your custom fields is how you want to store the information. Custom fields can usually be defined in a variety of data types such as a free-form text box, number, currency, date, checkbox, list, etc. It's important that you choose the correct data type BEFORE you activate your custom fields because once you start entering data into the field, there is a good chance the system will not allow you to change it.

The secret to choosing the right data type is to think about how you intend to use your custom field. For example, if you just want notes to inform your team, you should use the least restrictive option available to you, such as the simple 'text' type that lets the user put whatever they want into the field. But, if you intend to report on this data, or use it as a way to search or filter records, you may want a more structured field type, such as a pre-defined list of values the user must choose from.

Remember the old adage GIGO - Garbage In, Garbage Out.

Best Practices When Creating Custom Fields 

When you are ready to begin adding your custom fields, first do this little exercise: On a piece of lined paper, write out a list of the fields you are about to add, and take them to a co-worker who is not very well versed in this project (or even take them to a spouse or friend who isn't in the industry at all!) Give this person your list of fields and ask them to write next to each field what they think goes in that field, and to say out loud how they think that field will be used. If their answer doesn't match what you planned, you've got a red flag. This exercise can be invaluable, and save you a ton of trouble from bad planning down the road!

  • Red Flag #1: If the user doesn't understand what they are meant to do with that field - that is usually a bad field name. Look for something more descriptive. Use plain language and limit abbreviations.

  • Red Flag #2: If the user confuses the field with another field that is already in the system - either you actually did create a redundant field (in which case, you should look to see what you can consolidate or even eliminate), or you don't have enough contextual clues to let the user know what you expect. This can be a result of poor field organization. Group similar fields together to create context as to what you expect.

  • Red Flag #3: The user wants to put a value into the field that isn't allowed. For example, if you always want users to enter the inspection date the same way so you can report on it, but you set the field type to free-form text, don't be surprised if your users do their own thing. Set the field type to a date picker if you need to have that level of control.

Ultimate List of Sample Custom Fields 

These are real custom fields that are tracked by ream management professionals, for real communities. We compiled the list as a way to help kickstart your brainstorming session for setting up your own custom fields. At the end, we share some of the more unusual uses of custom fields we have encountered, and what they are being used for. Enjoy!


  • Annual Meeting Date
  • Board Meetings are Held On
  • Percent Required for Quorum
  • Other Policies
  • Trash Pickup Day
  • Recycling Pickup Day
  • Estoppel Processing Fee
  • Document Request Fee
  • Emergency Contact


  • Training Completed?
  • Date of Last Board Training
  • Term Expiration Date


  • Active CDs
  • Interest Rates
  • Maturity Dates


  • Parking Spaces
  • Gate Access Code
  • Boat Slip
  • RV Space
  • Bedrooms
  • Bathrooms
  • Garage
  • Water Heater Inspection Date


  • Pool Pass
  • Amenity Access Code
  • Birthday
  • Anniversary
  • Move-in Date
  • Move-out Date
  • Lease Start Date
  • Lease End Date
  • License Plate
  • License
  • Pet Breed
  • Service Animal (y/n)

Some of the more unusual but interesting custom fields we also have seen managers track: 

  • Shirt Size (for communities with a lot of events)
  • Children's Names (good to have on hand for events and phone conversations)
  • Pet Names / breed / size (particularly if your community restricts by size or breed) 
  • Appliances Installed (for unoccupied units, tracking community owned appliances for removal when the unit is sold)
  • Generator/Solar (helpful for communities in at-risk locations [e.g. for hurricanes]) 
  • Special Medical (used to track if a person in the household is on oxygen or has another medical dependency) 

What about you? Do you have any unusual data that you track in your community association?
Let us know in the comments below! (or ask Sue to do it!)  

Also, be sure to click the button below to register to watch my webinar on maintaining custom fields in TOPS [ONE]:

Click here to see a what your community looks like in TOPS [ONE].