Case Study 06: HomeNest Property Group — Q&A Preparation
AI-Generated Content — Use for Reference Only
This content is AI-generated and has only been validated by AI review processes. It has NOT been reviewed or validated by certified Salesforce CTAs or human subject matter experts. Do not rely on this content as authoritative or completely accurate. Use it solely as a reference point for your own study and preparation. Always verify architectural recommendations against official Salesforce documentation.
Q&A Format
Duration: 30 minutes following 30-minute presentation Strategy: State your position, give the reasoning, acknowledge the trade-off. Keep answers to 1-2 minutes.
Sharing & Security
Q1: With five user populations sharing one org, how do you prevent a misconfigured sharing rule from exposing tenant data to owners?
Private OWD is the foundation — no user sees anything unless explicitly granted. Tenants use sharing sets scoped to their Account-Contact relationship, which is a platform-enforced boundary that cannot be overridden by sharing rules. Owners use partner role hierarchy, which is isolated per partner account. These two mechanisms operate independently. I would add automated SOQL-based sharing validation tests in CI/CD that verify a sample tenant cannot query another tenant’s records.
Q2: Why Customer Community Plus for tenants instead of standard Customer Community?
Customer Community Plus supports sharing sets, which are required to scope tenant visibility to their specific unit and maintenance history. Standard Customer Community only supports sharing via the account hierarchy, which does not provide the per-unit isolation needed when multiple tenants share a Property account. The cost difference (~$3/user/month) is justified by the security requirement.
Q3: A leasing agent needs to see lease applications but not owner financials on the same Property record. How?
Field-level security on the leasing agent profile hides financial fields (NOI, owner distributions, management fee percentage). The agent sees the property address, unit details, and application data but not revenue or owner-facing metrics. Additionally, Restriction Rules on financial report types prevent agents from running reports that aggregate financial data. The agent’s page layout only includes leasing-relevant sections.
Q4: What happens when a technician is assigned to a property in Region A but their supervisor is in Region B?
Work Order assignment shares the Work Order and its parent Property with the assigned technician regardless of territory. The supervisor sees the Work Order through role hierarchy — FixRight GM is above Tech Supervisors, which rolls up to CEO. Territory-based sharing governs regional manager visibility, but the Field Service hierarchy (FixRight GM > Tech Supervisors > Technicians) is separate. There is no conflict because these are independent sharing mechanisms.
Multi-Org & Migration
Q5: During the 12-month coexistence, what if MuleSoft goes down and work orders stop syncing?
Anypoint MQ queues messages with automatic retry and dead-letter handling. If MuleSoft is unreachable, Platform Events replay from the last checkpoint (24-hour retention). Work orders queue in MuleSoft and sync when connectivity restores. Technicians are not blocked — they work in whichever org they are assigned to. A monitoring dashboard alerts the integration team if sync falls behind by more than 30 minutes.
Q6: Why not merge FixRight into the main org immediately and give external clients portal access?
Three reasons: FixRight’s external clients have contractual SLAs tied to FixRight’s existing processes and org. Rebuilding those workflows in the HNPG org is scope and budget risk. And 150 technicians learning a new system while serving two client bases increases error rates during the transition. The 12-month coexistence lets us migrate FixRight users to the HNPG org on a clean break when contracts expire, with no service disruption. The MuleSoft bridge cost is modest compared to the risk of a failed big-bang migration.
Q7: How do you handle FixRight’s 22 custom objects and 8 Apex triggers during migration?
Audit FixRight’s custom objects against the HNPG data model. Expect 40-50% to map directly to standard Field Service objects or HNPG custom objects. The remaining are FixRight-specific extensions (property access instructions, vendor parts tracking). Migrate those that have active data as custom objects in the HNPG org. Apex triggers are reviewed — if they replicate HNPG Flow logic, deprecate them. If they provide unique FixRight functionality, convert to Flows where possible. Migration happens at month 12-14 with a dedicated sprint.
Field Service
Q8: How does offline work for a technician in a parking garage basement with zero connectivity?
Field Service mobile app with offline briefcase. The briefcase pre-downloads assigned Work Orders, Service Appointments, property details, and contact information when the technician has connectivity. In the basement, the technician views work order details, logs time, captures photos, records parts used, and collects tenant signature — all stored locally. When the technician exits the basement and regains signal, the app automatically syncs. Conflict resolution: last-write-wins with server timestamp, though conflicts are rare because work orders are assigned to a single technician.
Q9: Preventive maintenance for 12,000 properties — how do you avoid overwhelming technicians with recurring work orders?
Preventive maintenance schedules use Maintenance Plans (standard Field Service object) with configurable frequency per property type. HVAC inspections quarterly for commercial, biannually for residential. Maintenance Plans generate Work Orders automatically based on the schedule, but assignment uses the scheduling optimizer to distribute across available technicians by skill, location, and capacity. Regional managers can pause preventive schedules during peak seasons (e.g., summer HVAC demand for emergency repairs in AZ/NV/TX).
Portals & Integration
Q10: 45,000 tenant logins on Experience Cloud — have you load-tested this assumption?
The architecture includes a dedicated load testing phase. Full Copy sandbox with synthetic 45K tenant dataset. k6 simulates 5,000 concurrent sessions (peak estimate based on 10-12% concurrent rate). Tenant portal is read-heavy — lease details and payment history are cached. Maintenance request submission is the primary write operation at 1,200/month (40/day), which is low. If load testing reveals bottlenecks, mitigation includes CDN caching, LWC lazy loading for maintenance history, and MuleSoft experience API caching for Yardi-sourced data.
Q11: Yardi is the system of record but Salesforce creates work orders. How do you avoid conflicting data?
Clear domain ownership. Yardi owns lease, financial, and tenant profile data. Salesforce owns work orders, maintenance requests, and technician operations. MuleSoft enforces this: Yardi-to-Salesforce sync is authoritative for lease fields (if Yardi and Salesforce disagree, Yardi wins). Salesforce-to-Yardi sync pushes work order costs for owner financial reporting but never overwrites lease or financial data. External IDs (YardiLeaseId, YardiPropertyId) on Salesforce records provide the correlation key. Conflict alerts notify the integration team if a sync detects a mismatch on a field that both systems should agree on.
Q12: The IoT platform covers only 120 properties. Is it worth building now?
Yes, but scoped appropriately. The IoT integration is lightweight: Particle webhooks to MuleSoft, MuleSoft evaluates thresholds, and alerts create Maintenance Requests via standard Salesforce APIs. The build cost is low (Phase 3, $0.6M shared with analytics). The architecture is scalable — adding a property means registering its sensors in Particle and creating Sensor Device records in Salesforce. No code changes. The alternative — waiting until 2,000+ properties have sensors — means retrofitting IoT into an architecture that was not designed for it.
Governance & Delivery
Q13: $3.8M for 18 months with only 10% contingency seems tight. Where do you cut if costs overrun?
Phase 3 (Smart Building + Analytics) is the buffer. IoT integration for 120 properties and CRM Analytics dashboards are valuable but not operationally critical. If Phase 1 or 2 overruns, Phase 3 scope reduces to IoT emergency alerts only (water leak auto-dispatch) and basic standard reports instead of CRM Analytics dashboards. The core platform, Field Service, and portals are non-negotiable — they solve the primary business problems.
Q14: How do you ensure the PHP portal decommission does not leave tenants stranded?
Three safeguards. First, wave-based migration (5K, 20K, 20K) with a pilot group that validates the experience before full rollout. Second, 30-day parallel run where both PHP portal and new tenant portal are active. Third, exit criteria for decommission: zero critical bugs, 95%+ tenant login success rate, and maintenance request submission rate matches or exceeds PHP baseline. If exit criteria are not met, the PHP portal stays active and the parallel run extends.
Q15: You chose MuleSoft for 8 integrations. Is that overkill compared to Salesforce-native integration?
Eight integrations, but the critical factor is Yardi bidirectional sync. Yardi is the financial system of record — if that sync fails silently, owner reports show wrong data and trust collapses. MuleSoft provides centralized monitoring, retry logic, and alerting that Salesforce-native tools (External Services, named credentials + Apex) cannot match at this reliability requirement. Add the FixRight bridge, IoT event processing, and Stripe webhooks, and the middleware layer justifies itself. If budget were tighter, I would consider Salesforce-native for DocuSign and Twilio (low-complexity, outbound-only) while keeping MuleSoft for Yardi and FixRight.
Question Categorization
| Domain | Questions |
|---|---|
| D1 System Architecture | Covered in presentation deep dives |
| D2 Security | Q1, Q2, Q3, Q4 |
| D4 Solution Architecture | Q12, Q15 |
| D5 Integration | Q5, Q11, Q12 |
| D6 Dev Lifecycle | Q7, Q13, Q14 |
| D3 Data / D5 Integration | Q6, Q10 |
| D7 Communication | Q8, Q9 |
Q&A Survival Rules
- Answer the question asked — do not pivot to a topic you prepared better for
- State position first, then reasoning: “I chose X because Y. I rejected Z because W.”
- Name the trade-off proactively — judges respect honesty over pretending there is no cost
- Say “I don’t know” when appropriate: “I would validate that during the design phase”
- Stay within 1-2 minutes per answer