Case Study 6: HomeNest Property Group - Presentation Notes

Work in Progress

This content is currently being reviewed for accuracy and will be updated soon.

Presentation Guide

This page turns the worked solution into a boardroom delivery outline. Use it after you have completed the case study and reviewed the reference solution.

Presentation Snapshot

Field	Detail
Open after	Worked Solution
Format	45-minute presentation + 45-minute Q&A
Study role	Rehearse structure, timing, and transitions
Related pages	Case Study Overview, Scenario Paper, Q&A Preparation

Presentation Focus

Go deep on the sharing model and multi-org coexistence, with the rest of the artifact set at supporting level.

Opening (3 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. Call out the three-phase program structure and $3.8M budget.

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

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

Show the sharing model table and role hierarchy diagram. Walk through each population:

• Property OWD is Private. This is non-negotiable — every sharing grant must be explicit.
• Regional managers: Criteria-based sharing rules on Property by Region for the 6 state regions (TX, AZ, CO, NV, CA, FL). Enterprise Territory Management is not used because it only supports Account, Opportunity, Case, and Lead — not custom Property. Building inherits via Controlled by Parent (M-D to Property). Unit, Lease, and Work Order are Private OWD with explicit sharing rules.
• Tenants (45K): Customer Community Plus Login licenses. A custom field Primary_Tenant_Contact__c (Lookup to Contact) on Unit, Lease, Maintenance Request, Work Order, and Payment is populated by a Flow when a lease activates. Sharing Sets on each of those objects resolve through that Contact lookup so a tenant in Unit 4B sees only Unit 4B’s lease, maintenance, work orders, and payments. Multi-tenant leases (roommates, co-signers) are handled by Apex Managed Sharing parallel rows. Unit uses Lookup to Building with Private OWD specifically to enable this per-unit isolation — if Unit were M-D with Controlled by Parent, a Sharing Set on Property would expose every unit to every tenant. Customer Community Plus is chosen over basic Customer Community because basic Customer Community does not support sharing rules, which the architecture needs for internal-to-external sharing on Lease and Payment.
• Owners (300): Customer Community Plus Member licenses. Each owner is a Contact under an Account with Record Type “Owner Portfolio” (IsCustomerPortal=true). Criteria-based sharing rules grant owners access to Properties where Owner_Account__c = $User.AccountId. Customer Community Plus is chosen over Partner Community because owners do not need the B2B sales objects (Lead, Opportunity, Campaign) and Partner role hierarchy does not automatically scope custom Property records to owners anyway — the actual mechanism is the criteria-based rule.
• Technicians: Field Service Mobile user license. Work Order assignment-based sharing grants Work Order access. Criteria-based Property sharing by Region gives technicians read access to properties in their assigned region for navigation only. Property access instructions (access codes, gate entry) are duplicated onto the Work Order itself, so the technician never needs to open the parent Property. FLS via Permission Set Groups hides lease terms, rent amounts, and financials from the technician profile. During the 12-month coexistence, FixRight technicians are NOT in the HNPG role hierarchy — they access HNPG work orders only via the MuleSoft bridge.
• Leasing agents: Criteria-based sharing rules on assigned properties only. See applications and lease data but not owner financials.

Emphasize: FLS via Permission Set Groups protects financial fields (not Restriction Rules, which control record-level access, not field visibility). No user population can accidentally escalate to see data outside their scope. Automated sharing verification tests run in CI/CD before every deployment.

Compliance architecture (Req 50, 52, 53): Shield Platform Encryption protects residual sensitive fields at rest (last four of SSN, driver license number). Event Monitoring captures read and update access events on financial data, with EventLogFile exported nightly to S3 for 7-year retention (native Event Monitoring retention is 30 days to 1 year — the external archive is mandatory for the 7-year audit requirement). Field Audit Trail captures change history on rent roll and owner distribution fields with up to 10 years of retention. Smart lock entry/exit events from Particle are correlated to Work Order assignments in MuleSoft and written to a Technician_Access_Log__c record for liability protection.

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

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

Show the integration architecture diagram with the FixRight bridge highlighted. 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 via Google Workspace JIT provisioning. FixRight org decommissioned.

Why MuleSoft bridge over S2S connection: S2S is a retiring feature; MuleSoft provides centralized monitoring, better error handling, transformation logic for different Work Order schemas, and is already in the stack for Yardi integration. Explain the error handling: Anypoint MQ with DLQ, 3-retry exponential backoff, PagerDuty alerting if sync falls behind 15 minutes.

Address FixRight data rationalization: 22 custom objects audited against HNPG data model, expect 40-50% to map to standard Field Service objects, remaining migrated or deprecated. 8 Apex triggers reviewed and converted to Flows where possible.

Supporting Artifacts (12 min)

System Landscape (1.5 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. Show Slide 1 - call out the legend (new/keeping/retiring).

Data Model (2 min): Show Slide 2. Owner is a standard Account with Record Type “Owner Portfolio” and Contact-based portal users (IsCustomerPortal=true). Residential Tenants Accounts are created per building to hold tenant Contacts. Property hierarchy: Owner Account -> Property (custom object with Owner_Account__c lookup) -> Building (M-D, Controlled by Parent) -> Unit (Lookup, Private OWD for per-tenant isolation). Primary_Tenant_Contact__c (Lookup to Contact) on Unit, Lease, Maintenance Request, Work Order, and Payment is the pivot field that Sharing Sets resolve through for tenant access; a Flow maintains it on lease activation and termination. Lease is Lookup to Unit with Private OWD (avoids 4-level M-D chain exceeding platform limit). Work Order and Service Appointment are standard Field Service objects with Private OWD (standard objects cannot use Controlled by Parent via custom M-D) — Service Appointment uses Field Service’s native assignment-based sharing plus role hierarchy, not Controlled by Parent. Work Order has a custom Property__c lookup plus duplicated access instructions for technician visibility without granting Property read. Yardi IDs as external keys on every synced object. Sensor Event stores only actionable alerts in Salesforce — raw telemetry streams from MuleSoft directly to the external data lake so the architecture supports 120 to 2,000+ properties without change (Req 29).

Integration (2 min): Show Slide 4. MuleSoft API-led with three layers (Experience, Process, System). Yardi is split into two directional patterns — scheduled inbound polling every 15 minutes via SOAP WSDL (Yardi Voyager Web Services, per-interface licensing), plus event-driven outbound updates when work orders close and cost data flows back. QuickBooks is a scheduled nightly batch (not event-driven) for owner reporting. Stripe webhooks through MuleSoft for payment tracking. TransUnion SmartMove is asynchronous by design — initial POST plus webhook callback after applicant consent (not synchronous request-reply). Particle IoT: raw telemetry streams from MuleSoft directly to the data lake; only actionable alerts land in Salesforce as Sensor Events and Emergency Maintenance Requests. Work order photos (up to 50MB per request) are offloaded to S3 with only the URL persisted on the Work Order — binaries never cross the MuleSoft bus. All SMS via Twilio as fire-and-forget. Walk through the error handling table briefly — highlight Yardi and IoT fallbacks plus the pre-provisioned Google group that activates FixRight dispatcher JIT provisioning during extended bridge outages.

Identity (1.5 min): Show Slides 7-10. Google Workspace SAML for 950 internal users; a MuleSoft orchestration reads Google groups nightly and assigns the matching Permission Set Groups via the PermissionSetAssignment SObject. Tenant portal: self-registration through a custom Apex registration handler (extends Auth.RegistrationHandler) that runs as a dedicated integration user, verifies email against Yardi, creates the User from a Contact under a Residential Tenants Account, sets Primary_Tenant_Contact__c, and assigns the Tenant Portal PSG. Owner portal: invitation-based registration with a separate handler that runs as integration user and assigns the Owner PSG based on the Contact’s PortalRole field. Mandatory TOTP MFA via Salesforce Identity Verification. Field Service mobile app (not standard Salesforce Mobile App): device trust for company tablets, SSO + mobile MFA for BYOD phones. Offline priming combines Field Service Mobile Settings for per-assignment work order data with Briefcase Builder (including High Volume Priming) for reference data that changes less frequently — Briefcase Builder does support Field Service mobile offline priming in current releases. FixRight technicians: existing credentials during coexistence in their own org (not in HNPG role hierarchy); at month 12, a SAML JIT handler (Apex class extending Auth.SamlJitHandler) creates their HNPG user with FieldServiceTechnician profile, Field Service Mobile license, and the Field Service PSG mapped from the Google group claim in the SAML assertion.

Data Migration (1.5 min): Yardi bulk load of 12K properties and 45K tenants with external keys preserved. FixRight historical work orders from SQL Server backup (~85K records). Tenant portal migration in waves (5K pilot, then 20K, then 20K). 30-day parallel run before PHP decommission. Data deduplication for overlapping FixRight/HNPG records.

Governance (1 min): Bi-weekly ARB with VP Technology chairing. Portal changes require UX review and load testing. Financial data changes require VP Finance sign-off. Flow-first automation; all integrations through MuleSoft. CoE established at month 2 with internal admins and developers.

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. Data masking for tenant PII in all non-production environments.

Roadmap (1 min): Show the Gantt chart. 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 and Risk Mitigation (3 min)

Three risks and mitigation:

1. Sharing model leakage: Private OWD on all key objects. Building inherits from Property via Controlled by Parent, but Unit and Lease use Lookup with Private OWD for per-tenant isolation. Sharing Sets applied directly on Unit (not Property). Work Order is Private with criteria-based and assignment-based sharing. No implicit sharing - every grant is auditable. Automated sharing verification tests in CI/CD catch misconfigurations before deployment.
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. FixRight GM reviews bridge changes jointly with VP Technology.
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. Exit criteria for PHP decommission: zero critical bugs, 95%+ login success rate.

“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.”

Contingency: If any deep dive runs long, compress the Supporting Artifacts section. System Landscape and Roadmap can be covered in 30 seconds each by pointing at the diagram and stating the sequencing rationale. Identity and Governance are the most compressible - cover only if time allows.

Timing Checkpoints

Segment	Duration	Cumulative
Opening	3 min	3 min
Sharing Model Deep Dive	12 min	15 min
Multi-Org Deep Dive	10 min	25 min
Supporting Artifacts	13 min	38 min
Closing and Risk Mitigation	4 min	42 min
Buffer	3 min	45 min

Contingency Plan

If the deep dives run long, compress Supporting Artifacts. System Landscape and Roadmap can each be covered in 30 seconds by pointing at the diagram and stating sequencing rationale. Identity and Governance are the most compressible sections.

Related Topics

• Case Study 06 Solution
• Q&A Preparation
• Presentation Structure
• Q&A Strategies

---

Always verify against official Salesforce documentation

This content is study material for CTA exam preparation. Content compiled and presented with AI assistance. Not affiliated with Salesforce.