Case Study 06: HomeNest Property Group — Presentation Notes

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.

Presentation Format

Total time: 30 minutes presentation + 30 minutes Q&A Strategy: Go deep on 2 high-risk decisions (sharing model, multi-org coexistence), supporting level on 7 artifacts

Opening (2 min)

“HomeNest Property Group manages 12,000 properties for 300 owners with 45,000 active tenants, and just acquired a maintenance company with 150 field technicians who have their own Salesforce org. The core architectural challenge is serving five distinct user populations — tenants, owners, regional managers, leasing agents, and technicians — each requiring sharply different visibility. My solution centers on a layered sharing model and a phased multi-org coexistence strategy.”

Show System Landscape. Frame the scale: 950 internal users, 45,000 tenant portal users, 300 owner portal users, 150 field technicians, 12,000 properties, 8 external integrations. State the single-org decision with dual Experience Cloud communities.

Deep Dive 1: Five-Population Sharing Model (8 min)

“Five user populations that must never see each other’s data. This is where the architecture succeeds or fails.”

Walk through each population:

• Property OWD is Private. This is non-negotiable — every sharing grant must be explicit.
• Regional managers: Territory-based sharing rules on Property, 6 state territories. Units, leases, work orders inherit via Controlled by Parent.
• Tenants (45K): Customer Community Plus licenses. Sharing sets scope visibility to the tenant’s Account-Contact relationship. A tenant in Unit 4B sees only Unit 4B’s lease and maintenance history.
• Owners (300): Partner Community licenses. Partner role hierarchy scopes each owner to their properties. An owner with 40 properties sees all 40 and their tenants — but not another owner’s portfolio.
• Technicians: Field Service licenses. Work Order assignment grants property access. Field-level security hides lease terms, rent amounts, and financials from the technician profile.
• Leasing agents: Sharing rules on assigned properties only. See applications and lease data but not owner financials.

Emphasize: Restriction Rules protect financial fields. No user population can accidentally escalate to see data outside their scope.

Deep Dive 2: Multi-Org Coexistence (7 min)

“FixRight has a functioning Salesforce org with 150 users and external clients under contract for 12 months. We cannot merge immediately.”

Walk through the three-phase approach:

1. Months 1-7: Build the HNPG org. MuleSoft bridge syncs HNPG-originated Work Orders to FixRight org. Technicians work in their familiar org. No disruption.
2. Months 7-12: Technicians begin using HNPG org for HNPG properties. External client work stays in FixRight org. Dual-org for technicians during this window.
3. Months 12-14: External contracts expire. FixRight users migrate to HNPG org. FixRight org decommissioned.

Why MuleSoft bridge over S2S connection: centralized monitoring, better error handling, transformation logic for different Work Order schemas, and MuleSoft is already in the stack for Yardi integration.

Supporting Artifacts (9 min)

System Landscape (1 min): Single HNPG org with Sales Cloud (leasing), Service Cloud (maintenance), Field Service (technicians), two Experience Cloud communities (tenant, owner). MuleSoft middleware to Yardi, Stripe, IoT, and FixRight bridge.

Data Model (1.5 min): Property hierarchy: Owner > Property > Building > Unit. Lease references Unit and Tenant Contact. Work Order is standard Field Service object extended with parts cost and owner approval. Yardi IDs as external keys on every synced object.

Integration (1.5 min): MuleSoft API-led. Yardi is bidirectional — Yardi masters lease/financial, Salesforce masters work orders. Stripe webhooks through MuleSoft for payment tracking. IoT alerts from Particle create emergency Maintenance Requests automatically. All SMS via Twilio triggered by Platform Events.

Identity (1 min): Google Workspace SAML for 950 internal users. Tenant portal: self-registration with email verification. Owner portal: invitation-based with MFA required. Field Service mobile: device trust for company tablets, SSO + MFA for BYOD phones.

Data Migration (1 min): Yardi bulk load of 12K properties and 45K tenants. FixRight historical work orders from SQL Server backup. Tenant portal migration in waves (5K pilot, then 20K, then 20K). 30-day parallel run before PHP decommission.

Governance (0.5 min): Bi-weekly ARB. Portal changes require UX review and load testing. Financial data changes require VP Finance sign-off. Flow-first automation; all integrations through MuleSoft.

Environments (0.5 min): Full Copy for load testing at 45K tenant scale. Separate Partial Copy for Field Service offline testing. Dev sandboxes per workstream.

Roadmap (1 min): 18 months in three phases. Field Service first (highest operational impact). Portals second (parallel tracks, different teams). Smart building third (limited scope today, designed for scale). FixRight migration at month 12 after contract expiry.

Transitions

• Opening to Sharing: “Let me start with the most complex architectural decision — how five user populations coexist on one org without data leakage.”
• Sharing to Multi-Org: “The fifth population — technicians — introduces the multi-org challenge. Let me show the coexistence strategy.”
• Multi-Org to Supporting: “With the two highest-risk decisions covered, let me walk through the remaining artifacts.”
• Supporting to Close: “Before I wrap up, the three biggest risks and how my architecture mitigates them.”

Closing (2 min)

Three risks and mitigation:

1. Sharing model leakage: Private OWD on all objects, Controlled by Parent inheritance, sharing sets and partner roles for portals. No implicit sharing — every grant is auditable.
2. Multi-org data inconsistency: MuleSoft bridge with Anypoint MQ for guaranteed delivery. Completion photos and time entries sync within 5 minutes. Monitoring dashboard alerts on sync failures.
3. Portal scale at 45K tenants: Wave-based migration with 5K pilot. k6 load testing at 5K concurrent in Full Copy sandbox. CDN caching for static content. Lazy loading for maintenance history.

“This is a property management platform where five user populations must see exactly what they need and nothing more — while an acquired company’s org coexists for 12 months. The architecture balances strict isolation with operational efficiency.”

Timing Checkpoints

Segment	Duration	Cumulative
Opening	2 min	2 min
Sharing Model Deep Dive	8 min	10 min
Multi-Org Deep Dive	7 min	17 min
Supporting Artifacts	9 min	26 min
Closing	2 min	28 min
Buffer	2 min	30 min