
A Salesforce implementation checklist for real estate covers eight phases: business requirements sign-off, data migration, integration setup, CRM configuration, user training, testing and UAT, go-live execution, and post-launch monitoring. Each phase must be verified before the next begins.
Most real estate Salesforce implementations don't fail because the platform is wrong. They fail because go-live was declared too early — before lead routing was tested, before the property management integration was validated, before agents had enough hands-on training to use the system on day one.
This checklist addresses each of those gaps, phase by phase, with real estate-specific items at every stage.
Implementation of work should not begin until requirements are fully documented and signed by business stakeholders. This phase ends when your implementation partner can build from what's on paper - not from verbal agreements that shift mid-project.
For real estate firms, the right questions to answer before configuration begins including: What are all the lead sources the team uses? What does the sales process look like from enquiry to booking for each property type? How are commissions calculated? Which team members need access to what data? What integrations are in scope?
☐ Document the full lead-to-booking process for every property type and sales channel
☐ Define all lead sources and how each will be captured in Salesforce
☐ Identify all systems that will connect to Salesforce and confirm API access is available
☐ Define user groups, roles, and data access requirements - and confirm that permission sets and permission set groups (not profiles) will be the primary vehicle for role-based access control, in line with Salesforce's current security model.
☐ Get written stakeholder sign-off before configuration begins
Changes after sign-off add cost and delay. The more complete this phase is, the fewer mid-project surprises you'll encounter.
Real estate firms typically carry lead, contact, property, and transaction data across spreadsheets, legacy CRMs, and property portals. Getting that data into Salesforce cleanly is one of the highest-risk parts of any implementation.
The data model needs to be defined first - Leads, Contacts, Opportunities, and custom objects for Properties/Units and Projects/Phases. Only after the model is confirmed can field mapping begin.
☐ Define the Salesforce object model and map every source field to the correct Salesforce field
☐ Run a test migration load in sandbox and validate record counts, relationships, and field values
☐ Run a second test load after corrections - confirm previous issues are resolved
☐ Get business users to sign off on migrated data quality before production migration begins
☐ Confirm the rollback plan before executing production migration
Never run production migration without a rollback capability. And never migrate data directly into production without at least two successful test loads in the sandbox.
For a real estate company, the Salesforce org connects to a property management system, a document signing platform, marketing tools, portal feeds, and often a financial system. Each integration needs to be built in sandbox, tested end-to-end, and validated under realistic data volumes before go-live.
☐ Yardi / MRI / AppFolio: Confirm that unit availability, pricing, and occupancy status sync on the correct frequency. Validate that inventory updates in the source system reflect in Salesforce within the agreed window
☐ Property portal feeds: Test lead capture from each portal, confirm that lead source is correctly tagged, and validate that assignment rules route leads to the right agent
☐ DocuSign: Test the full document workflow - booking agreement generation, signature request, and signed document attached to the Opportunity record
☐ WhatsApp Business API: Confirm that inbound enquiries create Lead records with the correct source tag and trigger the right assignment rule
☐ Test error handling for each integration: what happens when the external system is unavailable or returns a null value
Integrations that aren't tested with live data volumes before go-live will produce failures in production. The cost of a delayed launch is far lower than the cost of missing lead data in the first days of operation. Integration best practices for real estate architectures are covered in detail at developer.salesforce.com/blogs
Configuration covers everything from pipeline stages and leads routing to automation of flows, reports, and permission structures. Confirm the deployment of tooling before building begins. Salesforce now recommends DevOps Center (version-control-backed deployment, built into the platform) or Salesforce CLI-based CI/CD pipelines over legacy Change Sets. The deployment approach chosen here determines what the go-live deployment in Phase 7 looks like - and how reliably it can be rolled back if needed.
☐ Configure lead assignment rules for every active lead source - including edge cases like duplicate leads from the same portal
☐ Set up pipeline stages with required fields and validation rules at each stage transition
☐ Build core automation: lead follow-up task creation, site visit confirmation, booking agreement trigger, and escalation rules for no-contact leads
☐ Configure reports and dashboards that leadership needs on day one: lead volume by source, pipeline by stage, agent conversion rates, and inventory availability
☐ Test permission set groups and permission sets as an end user - not just as the admin account - for every persona before UAT begins. Profiles should carry only minimum access baseline settings"
One of the most common configuration mistakes in real estate implementations is building too many automation flows at once. Launch the core process automations and add complexity post-go-live once the team is stable on the platform.
Training is where most implementations underinvest. A single session in the week before go-live is not enough to change behavior for a team that has worked from spreadsheets and WhatsApp for years.
Training needs to be role-specific, built on sandbox data that mirrors real scenarios, and completed early enough that super-users can answer peer questions on launch day. Every agent should be able to independently complete the core workflow - create a lead, qualify it, log a site visit, advance the pipeline, generate a booking document — before go-live day arrives.
☐ Run separate training sessions for sales agents, team leads, property managers, and management
☐ Train super-users (one per team) two weeks before go-live so they can support peers on day one
☐ Confirm each user can complete core workflows independently after training
☐ Set the expectation clearly: parallel tracking in spreadsheets or legacy systems stops at go-live
If users cannot complete core workflows without prompting after training, training needs to run again before the launch date is confirmed.
UAT is not a one-day click-through. It's a structured testing cycle where actual business users test actual business scenarios in a UAT environment loaded with realistic data. Every critical business flow needs to be covered - not just the happy path.
☐ New lead arrives from each active portal and routes to the correct agent
☐ Agent advances a lead through all pipeline stages to Booking
☐ Booking triggers document generation and the correct agreement reaches the prospect
☐ Signed document is received and attached to the Opportunity record in Salesforce
☐ Closed deal appears correctly in the sales dashboard
☐ Team lead views their team's pipeline without seeing other teams' records
Log every issue with a severity rating - critical (blocks go-live), major (must fix before launch), minor (addressed in first post-launch update). Do not sign off on go-live readiness until all critical and major items are resolved. According to Salesforce Ben's consultant resources, skipped or abbreviated UAT is the most common pre-launch failure point across enterprise CRM rollouts.
By the time you reach launch day, all prior phases should be complete. If they aren't, push the go-live date. Launching open critical issues is not a calculated risk — it's a predictable failure.
☐ Deploy the final validated configuration package to production using the agreed deployment tool (DevOps Center, CLI pipeline, or change set) during a low-traffic window. - early morning before business hours
☐ Activate all integrations in production and run a quick validation test on each one
☐ Confirm every user can log in before the business day starts
☐ Run a production smoke test: create one lead, advance it through the pipeline, trigger a document, verify the dashboard. Do this in production, not in sandbox
☐ Deactivate the legacy CRM or tracking spreadsheets at the start of the business day so users cannot revert
☐ Have the implementation partner actively monitoring - not just on-call - for the first four hours after go-live
Go-live is not the finish line. The first 30 days will surface gaps that couldn't be predicted during design. The question is whether there's a structured process for catching and addressing them before they become habits.
Monitor integration performance and user adoption daily for the first two weeks. Look for users who are not logging in, leads arriving without a source tag, pipeline stages that aren't being updated, and any integration errors in the system logs.
Run a structured retrospective at the end of week one. Fix what needs to be fixed. Communicate the fixes to users. Then set a 30-day and 90-day review cadence to assess pipeline accuracy, data quality, and automation performance against the original requirements. Plan for a structured optimization cycle in the first 90 days — real-world usage consistently reveals configuration gaps that weren't apparent during design. A 30-day and 90-day review cadence is standard practice for well-run Salesforce implementations.
Going live before integrations are fully tested. Integration setup consistently takes longer than planned, and it's the phase most commonly cut short to hit a deadline. If the Yardi sync or portal lead feeds haven't been validated with production-level data, going live means going live with unknown failures in the most critical data flows.
Training only tech-savvy users. When time is short, training tends to focus on users who already show aptitude. This leaves the agents who most need support — often senior team members most resistant to change - without adequate preparation. Train everyone to the same minimum standard.
Launch all features at once. Trying to go live with every requested feature simultaneously produces a system so complex that users can't find the most important workflows. Launch the core pipeline, primary integrations, and critical reports. Add complexity to post-launch update cycles.
Skipping the production smoke test. A production deployment is not identical to a UAT deployment. Profile assignments, integration credentials, and automation activation states can all differ between environments. Run the smoke test every time.
For a mid-size real estate firm with 20 to 100 users, two to three integrations, and standard pipeline configuration, a well-run implementation takes 10 to 16 weeks from kickoff to go-live. More complex requirements - multiple Salesforce Clouds, large data migration, broker portal setup - typically require 20 to 28 weeks. The timeline compresses when requirements are clear, and the implementation partner has real estate-specific experience. It stretches when requirements change between mid-build or integration partners are slow to provide API access. See Minuscule's Salesforce implementation services for real estate-specific timelines.
Yes - if your agents reference unit availability or pricing during the sales process. If Yardi, MRI, or AppFolio is the source of truth for inventory and your agents need to check it while talking to prospects, the integration must be live on day one. Going live without it forces agents to switch between two systems to answer basic questions, which breaks the workflow Salesforce is meant to streamline. If the integration isn't ready, push the go-live date or define a clear manual process until it is.
No. Running parallel systems is the single biggest driver of data quality failure after go-live. When agents can use either system, they use the familiar one. Leads entered in the legacy system don't appear in Salesforce. Deals closed in a spreadsheet don't show in the pipeline. Deactivate or archive the old system on go-live day.
A reasonable baseline: 90%+ of sales users logging in daily, all inbound leads from primary sources captured within 24 hours, pipeline stage accuracy above 80%, and zero critical integration failures in the first two weeks. These aren't targets for perfection - they're confirmation that the system is functioning. Review and reset the targets for 30 days based on what you learned.
A Salesforce implementation for a real estate company is a structured project, not a technology deployment with a rough launch date attached. Every phase has a finish line; every finish line requires sign-off, and sign-off means the next phase starts on a solid foundation rather than an assumption.
Minuscule Technologies has delivered Salesforce implementations for real estate firms across property development, management, and sales - covering integration setups, data migration, and ongoing managed services. If your team is planning a Salesforce implementation or rethinking a go-live that is underdelivered, talk to our team or book a free strategic call.
You've seen what's possible. Now, let's make it happen for your business. Whether you need an end-to-end Salesforce solution, a complex integration, or ongoing managed services, our team is ready to deliver.
Schedule a Free Strategic Call