Leveraging our 20+ years of expertise in the real estate technology market, Metadata continuously engages with CIOs, CTOs, ERP leaders, and digital transformation teams across CRM evaluations, integration projects, and post-go-live operations. Through these conversations and implementation experiences, a consistent set of integration concerns repeatedly surfaced, particularly around exception handling, reconciliation, retries, monitoring, and ownership during transaction failures. Many organizations struggle to identify whether an issue belongs to IT, Finance, Operations, or the integration layer itself, leading to delays, escalations, and operational blind spots.
Every CRM vendor says they integrate. But when a transaction fails, most cannot tell you if it was IT’s fault or Finance’s fault. That distinction is the difference between a 10-minute fix and a 10-day blame storm. This blog is written based on those real-world industry learnings and implementation experiences. The 14 questions below are the questions real estate IT leaders should be asking in their next CRM vendor evaluation to separate genuine enterprise-grade integration capability from brochureware.
Q1. Which ERP systems are natively supported, and which require middleware or a custom API build?
Why this question matters: The answer must be specific to your ERP. A generic “we support it” tells you nothing. A good answer names your exact ERP (e.g., Oracle ERP Cloud, SAP S/4HANA, D365 F&O) and explains the architecture – native, API‑based, or middleware – with costs scoped upfront.
| ✅ What a good answer looks like | ❌ What a bad/evasive answer sounds like |
| “For Microsoft Dynamics 365 F&O or Business Central, Property‑xRM shares a common Dataverse database – no separate sync layer. For SAP or Oracle, we use structured middleware (Azure Integration Services, MuleSoft, or Boomi) with clear ownership and costs disclosed before signing. PropertyFlex on Salesforce connects via native AppExchange connectors.” | “We support most major ERPs. Our team will scope the integration during discovery.” |
Q2. What is the synchronization model: real‑time event‑driven, or scheduled batch processing?
Why this question matters: Batch synchronization is not real‑time. If your CRM pushes data every four hours, your finance team works off a lagging view. For month‑end close and audit readiness, that lag has real consequences.
| ✅ What a good answer looks like | ❌ What a bad/evasive answer sounds like |
| “Real‑time, event‑driven synchronization. On the Microsoft stack, the shared Dataverse layer guarantees it; for SAP/Oracle, real‑time is confirmed at middleware configuration. A transaction in the CRM triggers an immediate update in the connected ERP.” | “We support both real‑time and batch. It depends on your requirements.” (No confirmation for your specific ERP.) |
Q3. Is Excel still required anywhere in the workflow once the CRM and ERP are connected?
Why this question matters: Every manual data transfer point is where Excel lives. A fully integrated CRM should have no such steps. If someone is still copying numbers from one system to another, you do not have an integration – you have three systems.
| ✅ What a good answer looks like | ❌ What a bad/evasive answer sounds like |
| “No. Financial data, unit availability, payment schedules, booking records, and commission tracking all flow directly – no manual Excel step in the designed workflow. There is no point where a human transfers data between systems.” | “We can eliminate most spreadsheets. Some clients prefer to keep certain reports in Excel for flexibility.” |
Q4. Who builds and maintains the integration – your team, the vendor, or an SI?
Why this question matters: The integration build owner must be named in the contract, not implied. Vague language about “supported integration” without a named responsible party is one of the most common sources of post‑go‑live cost overruns and disputes.
| ✅ What a good answer looks like | ❌ What a bad/evasive answer sounds like |
| “We name the owner in the contract – whether Metadata, your internal IT team, or your SI partner. If we own the integration, we deliver it end‑to‑end and maintain it under a managed services agreement. Ownership is never left implied.” | “We will work with your team to ensure a smooth handover. Support is included in our standard contract.” |
Q5. When a transaction fails and then succeeds after a retry, does your integration automatically reconcile source totals to target totals?
Why this question matters: Retry without reconciliation leaves blind spots. A transaction can retry and succeed, but if the source system sent 100 invoices and the target received only 99, your finance team will never know – until month‑end reconciliation fails. If you cannot reconcile it, you do not own it.
| ✅ What a good answer looks like | ❌ What a bad/evasive answer sounds like |
| “Yes. Once the blocking condition clears – say, a closed period reopens – the transaction retries automatically. Then we compare summary totals from the source system to the target system to confirm nothing was missed. Reconciliation is a standard step, not an afterthought.” | “We have retry logic built in.” (No mention of reconciliation.) |
Q6. How does your team monitor failed and pending transactions – dashboards and end‑of‑day summaries, or just email alerts?
Why this question matters: Email alerts get ignored. Dashboards get watched. Your operations team needs to see failed transactions, pending retries, and success rates at a glance. If they point to email as their primary monitoring, they have not built enterprise‑scale integration.
| ✅ What a good answer looks like | ❌ What a bad/evasive answer sounds like |
| “You get a dashboard showing failed transactions, pending retries, and success rates in real time. We also send consolidated end‑of‑day summaries with counts and reasons for failure. Email alerts are available for critical exceptions, but your team watches a dashboard, not an inbox.” | “We send email notifications for every failure. Your team can set up filters to manage the volume.” |
Q7. Where in your flow do you check for duplicate records – before pushing to the target, or after?
Why this question matters: Once a duplicate enters the ERP, cleanup is manual, slow, and error‑prone. Duplicate prevention must happen at the beginning of the integration process, not after the fact. Both source and target systems must maintain unique identifiers, validated before push.
| ✅ What a good answer looks like | ❌ What a bad/evasive answer sounds like |
| “We validate unique identifiers at the very beginning – before any transaction is pushed to the target system. If a duplicate is detected, the transaction is blocked and logged for review. Duplicates never enter your ERP.” | “Our target system has duplicate detection rules, so duplicates are caught during posting.” |
Q8. Do failed transactions and retries count against my license consumption? How is high‑volume handling designed?
Why this question matters: In high‑volume scenarios (hundreds of thousands of invoices), a transaction that fails and retries five times counts as six against your license. A 10% failure rate with three retries adds 30% to your effective cost. Most vendors don’t disclose this. Also, low‑volume manual intervention does not scale – you need automated retry, monitoring, and exception handling from day one.
| ✅ What a good answer looks like | ❌ What a bad/evasive answer sounds like |
| “Yes, failed retries consume licensed capacity. We model five‑year total cost of ownership upfront, including your expected failure rates and retries. For high volume – hundreds of thousands of transactions – we use automated retry, structured monitoring, and controlled exception handling. Property‑xRM on Microsoft Dynamics uses Power Automate for lightweight orchestration and Logic Apps for complex high‑volume scenarios; PropertyFlex on Salesforce uses native async processing.” | “That’s a good question. Let me check with our licensing team. Our integration can handle high volume.” (No specifics.) |
Q9. How is data mapping handled, and what happens when records conflict between systems?
Why this question matters: Ask which system is master for financial data and which is master for sales and operational data. Any vendor who leaves conflict resolution undefined until after go‑live is creating a reconciliation problem for your team.
| ✅ What a good answer looks like | ❌ What a bad/evasive answer sounds like |
| “ERP is master for financial data; CRM is master for sales and operational data. We ship with native real estate data models for units, payment schedules, booking references, and project structures, reducing mapping effort. Conflict resolution rules are defined explicitly during implementation, not left open after go‑live.” | “We will define conflict rules during the data mapping phase. Most conflicts are resolved by keeping the most recent update.” |
Q10. Is the broker portal a native component, and does inventory reach brokers in real time?
Why this question matters: A broker portal that is a third‑party bolt‑on introduces its own integration dependency and its own potential for sync delays. In real estate, stale inventory at the moment of highest contention means lost deals and commission disputes. Confirm whether the portal is native to the platform and whether unit availability is updated in real time without manual refresh cycles.
| ✅ What a good answer looks like | ❌ What a bad/evasive answer sounds like |
| “The broker portal is native – not a bolt‑on. Brokers see real‑time inventory, register leads, track deals, and manage commissions inside the same data ecosystem. No manual sync, no spreadsheet workarounds.” | “We integrate with leading broker portals via API. The sync is near real‑time.” |
Q11. Where can approvals be actioned – only inside the CRM, or also from email or Teams?
Why this question matters: If approvals can only be completed from within the CRM interface, you have created a bottleneck that depends entirely on users being logged in when a decision is needed. Approvals should be actionable from email or collaboration tools your teams already use.
| ✅ What a good answer looks like | ❌ What a bad/evasive answer sounds like |
| “Approvals can be actioned from the CRM, email, or collaboration tools. Property‑xRM on Microsoft Dynamics handles approvals via Microsoft Teams; PropertyFlex on Salesforce does so natively within Salesforce. Your leadership doesn’t need to log into the CRM to approve a deal – they can respond directly from their inbox or chat.” | “Approvals are handled inside the CRM interface. Users can access the CRM from mobile devices.” |
Q12. How is your integration designed for high‑volume scenarios (hundreds of thousands of transactions)?
Why this question matters: Batch retries and manual exception handling work at low volume but fail at high volume. The integration must be designed for failure rates, retry logic, and capacity consumption from day one. Ask which volume tier their integration was built for.
| ✅ What a good answer looks like | ❌ What a bad/evasive answer sounds like |
| “Designed for high volume from day one. Automated retry logic, structured monitoring, and controlled exception handling – no manual intervention. Property‑xRM uses Power Automate for lightweight orchestration and Logic Apps for complex scenarios; PropertyFlex uses native async processing. Both have been tested at hundreds of thousands of transactions.” | “Our integration can scale to meet your needs. We’ll monitor and adjust as volumes grow.” (No specifics on design.) |
Q13. When our ERP upgrades (e.g., Oracle EBS to Fusion Cloud), who ensures the integration still works?
Why this question matters: ERP upgrades follow predictable cycles and each has the potential to break integration connectors. Maintenance responsibility must follow ownership and must be written into the support agreement before go‑live. Name the owner and the budget before signing.
| ✅ What a good answer looks like | ❌ What a bad/evasive answer sounds like |
| “We name the owner and the budget in the contract before go‑live. When the ERP upgrades, the target team exposes new web services; the integration team remaps the fields. Neither happens automatically. If we own the integration, we own the upgrade. Boundaries are written into the support agreement.” | “We’ll support it. Our team will work with you to ensure compatibility.” (No named owner, no budget.) |
Q14. When a transaction fails because the target system isn’t ready (closed period, missing master data), does your error log tell me that’s not an integration failure in plain language?
Why this question matters: If the error log lumps implementation failures and transactional failures together, your team will chase the wrong owner for every failure. The log should tell you, in plain English, who to call – not an error code that requires documentation lookup.
| ✅ What a good answer looks like | ❌ What a bad/evasive answer sounds like |
| “Yes. The error message clearly says something like ‘ERP period closed – resubmit when period reopens’ or ‘Master data missing – contact Finance team.’ You know immediately that the integration is fine; the business process needs attention.” | “We log all errors with a code. Your team can look up the code in our documentation or contact support.” |
Evaluation summary: What each question is testing
Use this table to score vendor responses. A vendor who cannot answer more than half with specificity should not advance.
| Question | What you’re testing | Metadata’s position |
| Q1 – ERP native vs. middleware | Specific ERP architecture + cost disclosure | Property‑xRM: Dataverse (no middleware); PropertyFlex: AppExchange; SAP/Oracle: structured middleware with upfront costs |
| Q2 – Sync model | Real‑time vs. batch, confirmed for your ERP | Real‑time, event‑driven; Dataverse layer guarantees on Microsoft stack |
| Q3 – Excel elimination | No manual data transfer in designed workflow | Financial data, units, payments, commissions flow directly – no Excel step |
| Q4 – Build ownership | Named owner in contract | Named in contract – Metadata, customer IT, or SI – never implied |
| Q5 – Retry + reconciliation | Retry and reconciliation both present | Automatic retry + source‑to‑target reconciliation |
| Q6 – Monitoring | Dashboard vs. email alerts | Dashboards + end‑of‑day summaries; email secondary |
| Q7 – Duplicate prevention | Validation before push, not after | Validated before target – duplicates never enter ERP |
| Q8 – Cost & scale | Failed retry licensing + high‑volume automation | Five‑year TCO modelled upfront. Property‑xRM: Power Automate + Logic Apps; PropertyFlex: native async |
| Q9 – Data mapping & conflicts | Master definitions + conflict resolution | ERP master for finance, CRM master for sales; conflict rules defined pre‑go‑live |
| Q10 – Broker portal | Native vs. bolt‑on, real‑time inventory | Native portal – real‑time inventory, lead, deal, commission |
| Q11 – Approvals | Actionable from email/Teams | Property‑xRM via Teams; PropertyFlex native |
| Q12 – High‑volume design | Built for scale, not manual intervention | Automated retry, monitoring, exception handling from day one |
| Q13 – ERP upgrades | Named owner + budget in contract | Upgrade ownership named in contract; boundaries in support agreement |
| Q14 – Plain‑language error log | Tells owner in plain English | Clear messages (“call Finance”) – not error codes |
Metadata’s Approach to Real Estate CRM Implementation
Metadata Technologies has completed 100+ real estate CRM implementations across 12+ countries in 20+ years of operation. Property-xRM is Microsoft AppSource-listed and Co-Sell Ready. PropertyFlex is Salesforce-native. Our 70+ in-house certified professionals serve an average client tenure of 5+ years. Every answer above is not a promise – it is how our platforms are built today.
The right questions separate real integration from brochureware
Integration is not a feature. It is an architectural commitment. The right question is not whether a CRM integrates, but what it costs, who owns it, how it behaves under load, and what happens when something breaks. A vendor who struggles to answer more than half of these questions with specificity has not designed for production reality.
If you are currently evaluating CRM partners, use these questions in your next vendor conversation. If you would like to put them to Metadata directly – and receive specific, evidenced answers to every one – we welcome the conversation.
Ready to put these questions to the test?
Apr 19, 2022
02:51:39pm 
