This article is for administrators who want a plain-English overview of where the WPResidence real estate CRM stores its data. You don’t need to open a database tool to follow along — we will explain what each table is for and why it matters.
Nine Tables, One Database
All your CRM data lives in your own WordPress database, in nine custom tables that the plugin creates the first time it activates. Each table has one clear purpose.
| Table | What it stores |
|---|---|
| Contacts | Every person you know — buyers, sellers, renters. |
| Leads | Each touchpoint from a contact (enquiry-by-enquiry). |
| Enquiries | Raw inbox items — every form submission. |
| Deals | Active transactions in your pipeline. |
| Tasks | Calls, meetings, and to-dos. |
| Activities | Timeline of every CRM event, system and human. |
| Notes | Short notes you attach to any record. |
| Viewed listings | Which properties each contact has looked at. |
| Automations | Rules that run themselves. |
How the Tables Relate
The nine tables are connected by ID references:
- Every lead, enquiry, deal, task, note, activity, and viewed listing points back to a contact.
- Deals can also point to a listing (your property posts) and to a handler agent (a WordPress user).
- Tasks can point to a contact and/or a deal.
- Activities can reference any of the above.
The net effect: everything in your CRM traces back to a contact. That is the root entity.
Why So Many Tables?
Because each kind of data has different shape:
- Contacts have 40+ columns — personal info, address, preferences, lifecycle.
- Activities are append-only event rows — a narrow schema, tens of thousands of rows on busy sites.
- Viewed listings are just who viewed what when — three columns, optimized for fast lookup.
Splitting by shape keeps queries fast and data organized.
What Is NOT Stored in These Tables
- Your property listings. Those live in WordPress’s posts table under the estate_property post type.
- Your agents. Those live in WordPress’s users table, plus an estate_agent post type for their profiles.
- Settings and configurations. Those live in WordPress’s options table as a single wpestate_crm_settings option.
- Email templates. Those live in Theme Options (Redux).
Two Legacy Post Types
Older versions of the CRM used WordPress custom post types (wpestate_crm_contact and wpestate_crm_lead) to store contacts and leads. These still exist but are no longer actively written to. On plugin activation, any legacy CPT records are migrated into the new custom tables automatically. The old CPT posts stay in place as a reference/archive and are not deleted.
Backups
A complete CRM backup is simply a backup of your WordPress database. When you back up the database:
- All nine CRM tables are included.
- All options (settings, permissions, webhook config) are included.
- All dashboard pages (as posts in the posts table) are included.
No separate “CRM backup” procedure is needed.
Data Export
If you want to take your CRM data out of WordPress, use the CSV Export feature. You can export contacts, deals, and tasks to CSV files — see the CSV Import / Export article.
Data Size and Performance
The CRM is designed to scale to tens of thousands of contacts and hundreds of thousands of activities without query slowdowns. Each table is indexed on the columns most commonly filtered (email, user_id, status, lifecycle_stage, stage, due_date). On very busy sites with hundreds of thousands of records, consult your hosting provider about database tuning.
Developer Information
For schema, column lists, indexes, foreign keys, and migration details, see the developer version of this article.