How EspoCRM fits a real estate agency's sales and listing workflow
EspoCRM with the free Real Estate extension can hold listings, buyer and seller requests, property matching and deal status in one self-hosted system. For an agency leader, the usual problem is that listings sit in one tool, client requests arrive by email or in a spreadsheet, and closed deals are recorded somewhere else, so nobody sees a single path from a request to a sale. In this setup, a sale or rent request is a record that can be matched against listings, and each listing carries its images and map location with it. The extension itself has no license fee, but hosting, implementation and configuration are separate costs that you will need to plan for.
What changes depends on the role. Agents work from requests and matches: they see which listings fit a client, record showings, and carry the agreed price into the opportunity, which the extension derives from markups. Office staff take on more responsibility for listing data, because matching, reporting and status updates depend on consistent addresses, images and status fields. Ask your implementation partner to confirm which matches run automatically and which an agent triggers, and to show how a markup changes an opportunity amount before go-live. Your own team should settle these rules, including who approves a status change to closed, before any build begins.
Self-hosting EspoCRM requires a supported PHP version, a supported database such as MariaDB 10.6 or newer, and a scheduled task for background jobs, as set out in the EspoCRM server configuration docs. Confirm which environment will host the system and who will run backups and upgrades, because matching and status updates rely on background jobs running on schedule. Also confirm that the Real Estate extension supports the EspoCRM version you choose before you commit to it, since the extension and core release cycles may not move in step.
Real estate requirements and what they mean for the build
This table maps each core agency requirement to the EspoCRM capability that supports it and the build decision it creates. Read each row as a design question to settle before configuration starts. The main takeaway is that matching, markup amounts and closing updates depend on formulas, workflows and background jobs, so each one needs testing with sample deals before go-live.
| Requirement | EspoCRM capability | Build decision |
|---|---|---|
| Listings with images and maps | Property listings with images and maps from the Real Estate extension | Decide which listing fields are public and which stay internal. Confirm where images are stored and which map service the extension uses. |
| Sale and rent requests | Client requests recorded as sale or rent requests from the Real Estate extension | Decide whether buyers and tenants share one request type or use separate types. The choice changes layouts, required fields and matching criteria. |
| Property and request matching | Matching between listings and requests, which depends on cron for background processing | Agree match criteria such as price band, area and property type in writing first. Confirm whether matches refresh on save or on a schedule, and set up cron to match. |
| Showings | Showings tracked against listings and requests in the Real Estate extension | Decide who books showings and whether agents see each other's schedules. Confirm the exact entities and any calendar integration needs in the extension documentation. |
| Opportunity amounts from markups | Amounts calculated with Formula Script in before-save scripts configured in the Entity Manager | Define the markup base, rounding rule and who may change markup values. Keep the formula under change control and test it against sample deals. |
| Status updates when deals close | Workflows and BPM from the Advanced Pack, included in all EspoCRM Cloud plans | Choose the closing stages that trigger updates. Confirm the Advanced Pack license terms for a self-hosted instance before designing workflows that depend on it. |
| Office and agent access | Roles and teams, plus OpenID Connect team mapping from the identity provider | Set team structure by office. Restrict owner details and private client data by role so agents see only the listings and requests they are allowed to handle. |
| Migrating existing listings and clients | CSV import with field mapping, duplicate matching on chosen fields and record reverting | Use a stable listing reference as the duplicate key. Test imports on a copy of the instance and confirm the revert steps before loading live data. |
| Website or portal feeds | REST API with dedicated API users and role-based permissions | Give the public site a dedicated API user with a narrow role. Use HMAC, which the docs describe as the most secure method, and avoid basic authentication. |
Which EspoCRM modules and settings shape a property CRM
A property CRM rests on a few decisions: how listings and client requests are modeled, how agents see them, how amounts and statuses are calculated, and who can view which branch's records. The cards below cover each decision and note what to confirm against the Real Estate extension's own documentation before the design is fixed.
Listing and request entities
The Real Estate extension adds the entities that hold property listings and client requests for sale or rent. Confirm the exact entity names, the fields each one ships with, and how a listing links to its images, map location and owning agent. These links determine every later step, so review them before you change any layout. Check whether the extension lets you add custom fields such as property type, branch or availability without modifying its code.
Property and request matching
Matching connects a client request to the listings that fit it. Decide whether the extension performs matching natively or whether you need a workflow or script to produce candidate lists. Define the criteria that count as a match, such as price range, location, size and transaction type, and decide how partial matches are handled. Test the rules against real historical requests, since edge cases like missing map coordinates often break matches.
Entity Manager and agent layouts
The Entity Manager controls which fields exist, and layouts control what each user sees on a record. Agents usually need listing details, linked requests and upcoming showings on one screen, while branch managers need a summary view. Plan separate layouts for each role, and confirm which panels and fields the extension expects so that a layout change does not hide data its logic depends on.
Formula script for markup-based amounts
Opportunity amounts often come from a listing price plus an agency markup. Formula Script is EspoCRM's built-in language for this, and it can run in before-save scripts configured in the Entity Manager. Define the markup rule in writing first, including whether it is a percentage or a fixed amount and which price field it starts from. Then confirm whether the extension already sets the amount, so two scripts do not overwrite each other.
Workflows for status changes at close
When a deal closes, the listing, the request and the opportunity usually need status updates together. The Advanced Pack provides the Workflows and Business Process Management needed to run those updates automatically. Confirm which extension version the Real Estate features depend on, whether your self-hosted edition requires the Advanced Pack license, and how a failed step is retried and logged before you rely on it for closing.
Teams and roles for branch visibility
Teams and roles decide which agent or branch sees which listings, requests and opportunities. Map your branch and agent structure to teams first, then set role permissions for each entity. Test visibility with a non-admin account from each branch, because an administrator sees everything and hides access gaps. If you later connect an identity provider, confirm how group mapping to teams will work before you assign access.
What agents, office managers and buyers each need from the system
Agents spend most of their working day in property listings, client requests and the schedule of showings. They need to see the properties they hold or are assigned to, match incoming requests against available stock, and record showings and feedback without waiting for an administrator. Access is usually shaped by teams and roles, so an agent sees their own branch's listings and the requests linked to them, but not confidential owner details on other agents' mandates.
- Listing screens: property records with images, map location, price and status, laid out so agents can update details quickly during a visit.
- Matching views: lists of open client requests that fit each listing, so agents can contact buyers and tenants first.
- Showings: scheduling and outcome notes linked to both the property and the client request.
- Opportunity amounts: the figures that carry into opportunities from markups, with a clear rule for which fields agents can edit after an offer.
Confirm with the vendor which of these views and fields the extension provides by default, and which need layout or role work in your instance.
Office managers need an overview across agents and branches: pipeline stages, listings that have stayed open too long, showing volume and deals that have closed. Their access should allow review without letting them change every agent's records. In EspoCRM this is typically handled with teams for branches and roles that grant read access at a wider scope than agents receive.
- Pipeline views: opportunities grouped by stage and branch, with amounts, to see where deals stall.
- Activity review: showings and client contacts per agent, to check that follow-up happens.
- Closing status: confirmation that listings and requests move to the correct status when a deal closes, so inactive records do not clutter active views.
- Scoped visibility: team-based access that limits managers to their branch, or gives company-wide views to a principal broker. Decide this before the build.
- Reports and dashboards: these come from the Advanced Pack, which the pricing page says is included in all EspoCRM Cloud plans. For a self-hosted instance, confirm your licensing for that add-on.
Ask for a walkthrough of the pipeline and branch views with test data before agreeing on the access scope.
Buyers, sellers, landlords and tenants may want to see their own requests and the status of a listing without full CRM access. Portal access is a separate role decision. A client needs only their own requests and linked properties, and must never see internal notes, other clients' data or markup and commission fields. Portal users should be treated as external identities with their own roles, layouts and security settings.
- Scope of visibility: clients see only their own requests and the listings linked to them.
- Hidden internal fields: markups, internal notes and agent-only data stay out of portal layouts.
- Sign-in method: decide whether clients use a local portal account or an identity provider. EspoCRM supports OpenID Connect, but its own two-factor authentication is not compatible with OIDC, so second-factor controls for those users must be planned at the identity provider.
- Security settings: the security documentation recommends a password policy, two-factor authentication where it applies and IP restrictions for administrative access. Confirm which of these apply to portal users.
Ask the implementer to map each portal view and field to a named role, then test it with a client account before opening access to anyone outside the agency.
How a real estate EspoCRM rollout is sequenced
The sequence moves from agreeing how listings and client requests are modeled to a tested, trained and cut-over agency instance, so each phase hands a verified output to the next. Each step names what is decided or built and how the team confirms it is finished.
Confirm the listing and request model
The agency and the implementation team agree how listings, client requests for sale or rent, contacts, owners and opportunities relate to each other, and which fields drive matching, showings and deal status. Agency principals, sales leads and office administrators take part, since they own the workflow. The step closes with a signed-off data model document that lists every entity, relationship and status value, and the matching rules that connect requests to properties. Ask the partner to show how the Real Estate extension's entities map to your model before any build begins.
Decide hosting and identity
The team chooses where EspoCRM runs, whether on servers or cloud accounts the agency controls, and how staff sign in. Infrastructure and security leads confirm the supported stack in the EspoCRM server configuration docs, including PHP, the database engine, the web server and cron for background jobs. They also decide whether staff sign in through an existing identity provider using OpenID Connect or LDAP, how two-factor authentication applies, and which IP restrictions apply to admin access. The step is complete when the environment, sign-in design and access policy are documented and approved by the security owner.
Build entities, layouts and matching logic
Using the Entity Manager and the Real Estate extension, the team configures property and request entities, detail and list layouts, and the formula logic that calculates opportunity amounts from markups and sets status changes when deals close. Formula scripts run in before-save scripts, workflows and BPM, so the team decides where each rule lives and records it. Listing images and map fields are configured and tested on sample records. The output is a configured non-production instance and a rule register that names each formula, its trigger and its owner.
Import existing listings and contacts
Existing property and contact data is cleaned, mapped to the new fields and loaded with the CSV import. The team chooses between Create Only, Create and Update, and Update Only modes for each file, sets duplicate matching on chosen fields such as a listing reference or contact email, and runs large files through cron. Imports are first run on a copy to check field mapping and duplicate handling. Completion means row counts reconcile against the source files, duplicate rates are reviewed by the agency, and the team knows how to revert an import if a mapping error appears.
Test matching and status logic with sample data
Before real clients are involved, the team loads sample agency data that covers sale and rent requests, edge cases such as price changes, withdrawn listings and duplicate contacts, and a range of markup values. Testers confirm that requests match the right properties, that showings are scheduled and recorded against the correct records, that opportunity amounts calculate as the agency expects, and that status updates fire when a deal closes. Each failed case is logged, fixed and retested. The step closes with a signed test log that the agency's sales lead approves.
Train staff and cut over
Office staff, agents and administrators are trained on the workflows they will use each day, with role-specific guidance that reflects the permissions they were given. The team agrees a cutover window, runs a final import of changed records, switches the agency's daily work to the new instance and keeps the previous system read-only for an agreed period. Admin accounts are kept separate from daily-use accounts, as the EspoCRM security docs recommend. Cutover is complete when all active agents work in the new instance, the first live matches and status updates are checked, and a backup and recovery procedure is in place.
Personal data and access controls a property agency must plan for
A property agency holds identity documents, financial details and home search histories for its clients, and its staff and listing-portal feeds all reach that data. The controls below decide who can see which records, how people sign in, and how automated feeds authenticate, so they should be designed before the first client record is imported.
Client personal data in requests
Sale and rental requests often carry names, phone numbers, email addresses, budgets, household details and viewing preferences. Decide which of these fields are required, who can read them through teams and roles, and how long closed requests stay in the system. Ask counsel which retention periods and lawful bases apply in each market you operate in, then configure the Entity Manager and layouts to match.
IP allowlists for staff access
Restricting logins to office networks and approved VPN ranges limits exposure of client records if a staff password is leaked. Agencies with field agents or home offices need a plan for exceptions, such as a time-limited allowlist entry or a documented remote access route. Confirm how your staff connect today and test the allowlist with each group before enforcement.
Enforced two-factor authentication
The security guidance recommends requiring two-factor authentication for all users. Because EspoCRM's own 2FA is not compatible with OIDC sign-in, the choice of identity provider changes where the second factor is enforced. Decide this before onboarding, and plan recovery steps for staff who lose their device.
Separating admin and daily accounts
Administrators who also sell properties create a risk, because a phished session carries full configuration rights. Give each administrator a separate account for configuration work and a standard account for listings and requests. Pair this with restricted password recovery for admin accounts so that recovery does not become an easy takeover path.
API users for listing-portal feeds
Portal feeds that push listings or pull requests should run as dedicated API users with narrow role permissions, not as a person's login. The REST API supports HMAC, which the docs describe as the most secure option, while basic authentication is not recommended. Confirm which authentication method your portal supports, and rotate or revoke keys when a feed vendor changes.
Evidence for assessors
DeployOpen prepares controls, configuration records and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications. Independent auditors and certification bodies perform those assessments. Ask your counsel and assessor which evidence they expect, such as role exports and access reviews, and agree on who keeps it current.
What real estate agencies ask before implementing EspoCRM
What drives the cost of implementing EspoCRM for a real estate agency?
Scope drives most of the cost: how many property types you track, how many listing fields you need, how images and maps are handled, how matching rules are written, how showings are booked, and how many systems the CRM must connect to. Data migration from spreadsheets or an older CRM adds work in proportion to the number of records and the cleanup they need. Costs fall into one-time work (design, configuration, testing, training, cutover) and recurring costs (hosting, staff time, and any cloud subscription). Ask for a quote that lists each area separately, states what is excluded, and names who performs each task so you can compare it with the work your own team would absorb.
Can an agency deploy EspoCRM and the Real Estate extension without a partner?
Yes, in principle. The open-source edition of EspoCRM can be downloaded and self-hosted for free, and the Real Estate extension is described as free. The harder part is operating the stack: a Linux server, a supported PHP and database version, a web server, TLS certificates, scheduled background jobs, backups, and access control. Configuration work such as entities, layouts, formula logic, matching rules and the listing workflow also takes time from people who know both your sales process and the platform. Agencies with an internal IT or platform team and a clear owner for the CRM can often do this in-house. Agencies without that capacity usually need a partner for implementation, then a support arrangement after go-live.
How long does setup take for a large listing catalog?
Setup length depends mainly on data volume and listing complexity, not on the number of users. A catalog with many properties, multiple photos per listing, map positions for each address, and detailed attributes takes longer to model, import and check than a small set of simple listings. Bulk imports are handled by CSV import, which supports field mapping, duplicate matching on chosen fields, and idle execution through cron for large files, so large loads run in the background. Matching rules between properties and client requests need testing against real sample data. The schedule should come from a written scope that breaks the work into design, build, migration, testing and go-live, with the dependencies between them stated.
What must the agency provide before implementation starts?
The agency must supply decisions and data that only its own staff can give. Typical inputs include:
- Listing data exports and a sample of listings with photos and addresses
- Property types, sale and rent categories, and the attributes each needs
- The client request forms, budgets, areas and criteria used for matching
- Pipeline stages for sales and lettings, plus the rules for markups and opportunity amounts
- User roles, teams and who may see which listings or clients
- Access to the target server or cloud account, DNS and mail settings, and any identity provider
- A named decision-maker who approves changes and signs off testing
Missing inputs are the most common cause of delay, so ask the partner to list each input and its owner in the written scope.
How is hosting cost set for a self-hosted EspoCRM?
A self-hosted EspoCRM has no license fee for the open-source edition, so hosting cost comes from the infrastructure you choose. That includes compute and storage in your cloud account or data center, extra storage for listing images, backups, TLS certificates, monitoring, and the staff time to patch and upgrade. The EspoCRM Cloud option is priced per user per month: 15 US dollars on the Basic plan (minimum 3 users), 25 dollars on Enterprise (minimum 5 users), and 69 dollars on Ultimate (minimum 10 users), with the Advanced Pack included in all cloud plans, according to the EspoCRM pricing page. Confirm whether the Real Estate extension is available on the plan you pick, and ask the partner to show hosting cost separately from implementation cost.
How do EspoCRM upgrades affect the Real Estate extension?
An extension must match the EspoCRM version you run, so every platform upgrade needs a compatibility check before it is scheduled. EspoCRM 9.0.0 was released on January 20, 2025, and 10.0.0 on July 2, 2026, with 10.0.10 following on October 14, 2026, according to the EspoCRM releases page. Since version 10.0, upgrading through the UI is disabled by default, so upgrades run through the command line. Plan each upgrade in a staging copy that includes the Real Estate extension, your layouts, formulas and listing data, then test matching, images, maps and status updates before production. Confirm the extension's supported versions with the vendor before you commit to a target release.
What server stack does EspoCRM need to run?
EspoCRM runs on PHP 8.3 to 8.5 with MySQL 8.0 or newer, MariaDB 10.6 or newer, or PostgreSQL 15, served by Apache, Nginx or IIS. Background jobs require cron or a scheduled task, which matters for imports, email and matching jobs. For Ubuntu, Debian and Linux Mint, EspoCRM provides an installation script that deploys a Docker-based stack with Nginx and MariaDB, optional Let's Encrypt certificates, and a command.sh utility for backups, restores and upgrades. Check the server configuration documentation for the version you plan to run, and confirm the extension supports the same PHP and database versions before you fix the stack design.
How DeployOpen scopes and delivers a real estate EspoCRM implementation
DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure. For EspoCRM for real estate agencies, we start from how your agents, coordinators and managers handle listings, client requests and closings, then build on the official Real Estate extension and configure only what your workflow needs.
How we scope
- Written scope covering listing fields, request types, matching rules and showing workflows agreed before any build starts
- Inventory of your current listing sources, client intake channels and the people who own each status update
- Decisions on hosting location, identity provider, mailboxes and which integrations are in scope, recorded in the scope document
- Engagements are fixed-scope, so deliverables and timelines are agreed in writing before work begins, and quotes follow from that scope
How we build
- Configure the Real Estate extension with your property types, listing images, map fields and request categories in a test instance first
- Set up formula logic for opportunity amounts from markups, plus assignment and status rules agreed during scoping
- Load test property and request records, then verify matching results, showing schedules and status transitions against agreed test cases
- Document each custom field, layout and script so your administrators can maintain them after handover
How we hand over
- Production cutover plan with a rollback path, backup verification and admin account separation for daily work
- Security settings reviewed against the EspoCRM security documentation, including password policy, 2FA and IP restrictions
- Admin training sessions and written runbooks covering listing updates, request handling and common troubleshooting steps
- Handover of configuration, documentation and access records so your team owns the running system
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover
- Upgrade planning for new EspoCRM releases, including review of the Real Estate extension and any custom scripts before each change
- Change requests handled through the same written scope process used at the start of the engagement
- Ask any provider to confirm response times, support hours and upgrade responsibilities in writing before you sign
