Case Study 06: HomeNest Property Group — Worked Solution

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.

Solution Context

Heavy domains: D1 System Architecture, D2 Security, D5 Integration | Difficulty: Intermediate Time budget: 180 minutes | Key frameworks: 9 Essential Artifacts

Attempt the Scenario First

If you have not yet worked through the scenario paper, stop here. Set a 180-minute timer and build your own solution before reading this one.

Assumptions

1. Single org for HNPG with Salesforce-to-Salesforce (S2S) or MuleSoft bridging to FixRight’s org during 12-month coexistence. FixRight users migrate to the main org as external contracts wind down. Rejected immediate org merge because FixRight must maintain its external client operations independently.
2. Sales Cloud + Service Cloud + Field Service + Experience Cloud (two communities) — Sales Cloud for leasing, Service Cloud for maintenance case management, Field Service for 150 technicians with offline mobile, Experience Cloud for tenant and owner portals.
3. Yardi remains system of record for lease/financial data. Salesforce holds operational copies synced via middleware. Rejected replacing Yardi because it handles complex property accounting (CAM reconciliation, owner distributions) that Salesforce cannot replicate within budget.
4. MuleSoft Anypoint as integration middleware — 8 external systems, dual-portal traffic, IoT events, and Yardi bidirectional sync require centralized orchestration and monitoring. Rejected point-to-point because Yardi sync reliability is critical and needs a single monitoring layer.
5. Field Service Mobile with offline-first architecture — 150 technicians using Salesforce Field Service mobile app with offline briefcase configuration. Covers zero-connectivity scenarios in basements and garages.

Key Architectural Decisions

Decision 1: Multi-Portal Architecture (D1/D2)

Two Experience Cloud communities on the main org:

• Tenant Portal — Customer Community Plus licenses for 45,000 tenants. Sharing sets scoped via Account (property) and Contact (tenant). Tenants submit maintenance requests, view lease details (read-only from Yardi), and track work order status.
• Owner Portal — Partner Community licenses for 300 owners. Partner role hierarchy gives each owner visibility to their properties only. Owners view dashboards, approve high-cost maintenance, and download financial statements.

Rejected a single portal with role-based views because tenant and owner data models, security requirements, and license economics are fundamentally different. Customer Community Plus at ~$8/user/month for tenants vs. Partner Community at ~$25/user/month for 300 owners is cost-effective.

Decision 2: Five-Population Sharing Model (D2)

Population	License	OWD on Property	Visibility
Regional Managers	Internal (Full)	Private	Territory-based sharing rules for their region
Leasing Agents	Internal (Full)	Private	Sharing rules on assigned properties only
Technicians	Internal (Field Service)	Private	Work Order assignment grants property access
Tenants (45K)	Customer Community Plus	Private	Sharing set via Account-Contact relationship
Owners (300)	Partner Community	Private	Partner role hierarchy scoped to owned properties

Property is Private OWD. Work Order is Controlled by Parent (inherits from Property). Lease, Unit, and Maintenance Request all inherit via Controlled by Parent. This ensures no lateral visibility between tenants, no cross-portfolio visibility between owners, and no cross-region visibility between managers.

Decision 3: Multi-Org Coexistence (D1/D5)

FixRight’s org runs independently for 12 months serving external clients. HNPG-assigned work orders route to FixRight technicians via MuleSoft:

• HNPG org creates Work Order, publishes Platform Event
• MuleSoft catches the event, creates corresponding Work Order in FixRight org
• FixRight technicians complete work in their org
• MuleSoft syncs completion status, photos, and time back to HNPG org

At month 12, FixRight external contracts expire. Technician users migrate to HNPG org with Field Service licenses. FixRight org decommissioned. Rejected Salesforce-to-Salesforce connection because MuleSoft is already in the stack and provides better monitoring, error handling, and transformation.

Artifact 1: System Landscape

graph TB
    subgraph LEGEND["Legend"]
        L1["🟢 NEW — being built"]
        L2["⚪ KEEPING — no changes"]
        L3["🔴 RETIRING — decommission"]
        L4["🟠 INTEGRATION LAYER"]
    end

    subgraph SF["HNPG Salesforce Org"]
        SC[Sales Cloud — Leasing]
        SVC[Service Cloud — Maintenance]
        FSL[Field Service — Technicians]
        TP[Experience Cloud — Tenant Portal]
        OP[Experience Cloud — Owner Portal]
    end

    subgraph MW["MuleSoft Anypoint"]
        EXP[Experience APIs]
        PROC[Process APIs]
        SYS[System APIs]
    end

    subgraph EXT["External Systems"]
        YARDI[Yardi Voyager]
        QB[QuickBooks Enterprise]
        STRIPE[Stripe Payments]
        TU[TransUnion SmartMove]
        DS[DocuSign]
        TWILIO[Twilio SMS]
    end

    subgraph IOT["IoT Platform"]
        PARTICLE[Particle Cloud]
        LOCKS[2,400 Smart Locks]
        HVAC[1,800 HVAC Sensors]
        WATER[600 Leak Detectors]
    end

    subgraph FIX["FixRight Org — 12-month coexistence"]
        FRSVC[Service Cloud]
        FRFS[Field Dispatch]
    end

    subgraph ID["Identity"]
        GOOG[Google Workspace — SAML 2.0]
    end

    SF -->|Platform Events + CDC| MW
    TP -->|REST real-time| EXP
    OP -->|REST real-time| EXP
    EXP --> PROC
    PROC --> SYS
    SYS -->|REST/SOAP bidirectional poll 15min| YARDI
    SYS -->|REST batch nightly| QB
    SYS -->|REST webhooks| STRIPE
    SYS -->|REST request-reply| TU
    SYS -->|REST callbacks| DS
    SYS -->|REST fire-and-forget| TWILIO
    SYS -->|MQTT/webhooks| PARTICLE
    MW <-->|REST bidirectional WO sync| FIX
    GOOG -->|SAML 2.0 SSO| SF

    style SC fill:#2e7d32,color:#fff
    style SVC fill:#2e7d32,color:#fff
    style FSL fill:#2e7d32,color:#fff
    style TP fill:#2e7d32,color:#fff
    style OP fill:#2e7d32,color:#fff
    style EXP fill:#e65100,color:#fff
    style PROC fill:#e65100,color:#fff
    style SYS fill:#e65100,color:#fff
    style YARDI fill:#9e9e9e,color:#000
    style QB fill:#9e9e9e,color:#000
    style STRIPE fill:#9e9e9e,color:#000
    style TU fill:#9e9e9e,color:#000
    style DS fill:#9e9e9e,color:#000
    style TWILIO fill:#9e9e9e,color:#000
    style PARTICLE fill:#2e7d32,color:#fff
    style LOCKS fill:#9e9e9e,color:#000
    style HVAC fill:#9e9e9e,color:#000
    style WATER fill:#9e9e9e,color:#000
    style FRSVC stroke:#c62828,stroke-width:3px,stroke-dasharray: 5 5
    style FRFS stroke:#c62828,stroke-width:3px,stroke-dasharray: 5 5
    style GOOG fill:#9e9e9e,color:#000

Artifact 2: Data Model

erDiagram
    OWNER ||--o{ PROPERTY : owns
    PROPERTY ||--o{ BUILDING : contains
    BUILDING ||--o{ UNIT : has
    UNIT ||--o{ LEASE : governs
    LEASE }o--|| TENANT_CONTACT : signed_by
    UNIT ||--o{ MAINTENANCE_REQUEST : generates
    MAINTENANCE_REQUEST ||--|| WORK_ORDER : creates
    WORK_ORDER }o--|| TECHNICIAN : assigned_to
    WORK_ORDER ||--o{ SERVICE_APPOINTMENT : scheduled_as
    PROPERTY ||--o{ SENSOR_DEVICE : monitored_by
    SENSOR_DEVICE ||--o{ SENSOR_EVENT : emits
    LEASE ||--o{ PAYMENT : tracks

    OWNER {
        string Name
        string PortalUserId
        picklist OwnerTier
    }
    PROPERTY {
        string PropertyName
        picklist Type "Residential / Commercial"
        picklist Region "TX / AZ / CO / NV / CA / FL"
        lookup Owner
        number TotalUnits
        percent OccupancyRate
    }
    UNIT {
        string UnitNumber
        picklist Status "Occupied / Vacant / Maintenance"
        currency MonthlyRent
        lookup CurrentLease
    }
    LEASE {
        date StartDate
        date EndDate
        currency MonthlyRent
        picklist Status "Application / Active / Renewal / Terminated"
        string YardiLeaseId
    }
    WORK_ORDER {
        picklist Priority "Emergency / Urgent / Standard / Preventive"
        picklist Status
        string CompletionPhotos
        number LaborHours
        currency PartsCost
    }
    SENSOR_DEVICE {
        picklist Type "Lock / HVAC / Water"
        string DeviceId
        picklist Status "Active / Offline / Alert"
    }

• Property hierarchy (Owner > Property > Building > Unit) enables roll-up summaries and scoped sharing.
• Lease references both Unit and Tenant Contact; YardiLeaseId is the external key for sync.
• Work Order uses standard Field Service object, extended with custom fields for parts cost, completion photos, and owner approval status.
• Sensor Device and Sensor Event are lightweight — events older than 90 days archived. Alerts create Maintenance Requests automatically.

Artifact 3: Role Hierarchy & Sharing Model

graph TB
    CEO["CEO"]
    CEO --> VPTech["VP Technology"]
    CEO --> VPProp["VP Property Mgmt"]
    CEO --> VPFin["VP Finance"]
    CEO --> FixGM["FixRight GM"]

    VPProp --> RMTX["Regional Mgr — TX"]
    VPProp --> RMAZ["Regional Mgr — AZ"]
    VPProp --> RMCO["Regional Mgr — CO"]
    VPProp --> RMFL["Regional Mgr — FL"]
    RMTX --> LATX["Leasing Agents — TX"]
    RMTX --> PMTX["Property Mgrs — TX"]
    RMAZ --> LAAZ["Leasing Agents — AZ"]

    FixGM --> TECHSUP["Tech Supervisors"]
    TECHSUP --> TECHS["Field Technicians"]

Object	OWD	Sharing Mechanism
Property	Private	Territory-based sharing (6 state territories)
Unit	Controlled by Parent	Inherits from Property
Lease	Controlled by Parent	Inherits from Unit
Work Order	Controlled by Parent	Inherits from Property + technician assignment
Maintenance Request	Controlled by Parent	Inherits from Unit
Owner (Account)	Private	Direct ownership; portal partner roles
Tenant (Contact/Account)	Private	Sharing set scoped to Account-Contact relationship
Payment	Controlled by Parent	Inherits from Lease

Technician visibility: Technicians see Work Orders assigned to them (assignment-based sharing). The parent Property record is shared via work order lookup, but only property access information (address, access codes, gate instructions) is exposed via field-level security. Lease terms, rent amounts, and owner financials are hidden from the technician profile.

Restriction Rules: Financial fields on Property (revenue, owner distributions, NOI) restricted to VP Finance role and Owner portal profile only.

Artifact 4: Integration Architecture

graph LR
    subgraph LEGEND["Legend"]
        L1["🟢 NEW"]
        L2["⚪ KEEPING"]
        L3["🔴 RETIRING"]
        L4["🟠 INTEGRATION LAYER"]
    end

    subgraph SF["Salesforce"]
        PE[Platform Events]
        CDC[Change Data Capture]
        REST_IN[Inbound REST]
    end

    subgraph Mule["MuleSoft Anypoint"]
        EXP["Experience APIs"]
        PROC["Process APIs"]
        SYS["System APIs"]
        AMQ[Anypoint MQ]
    end

    subgraph EXT["External Systems"]
        YARDI[Yardi Voyager]
        QB[QuickBooks]
        STRIPE[Stripe]
        TU[TransUnion]
        PARTICLE[Particle IoT]
        DS[DocuSign]
        TWILIO[Twilio]
        FIXR[FixRight Org]
    end

    PE -->|Platform Events publish| Mule
    CDC -->|CDC events — Property/WO changes| Mule
    Mule -->|REST/Bulk API| REST_IN
    EXP --> PROC
    PROC --> SYS
    PROC --> AMQ
    AMQ --> SYS
    SYS -->|REST/SOAP poll 15min| YARDI
    SYS -->|REST batch nightly| QB
    SYS -->|REST webhooks| STRIPE
    SYS -->|REST request-reply| TU
    SYS -->|MQTT/webhooks| PARTICLE
    SYS -->|REST callbacks| DS
    SYS -->|REST fire-and-forget| TWILIO
    SYS <-->|REST bidirectional WO sync| FIXR

    style PE fill:#1a73e8,color:#fff
    style CDC fill:#1a73e8,color:#fff
    style REST_IN fill:#1a73e8,color:#fff
    style EXP fill:#e65100,color:#fff
    style PROC fill:#e65100,color:#fff
    style SYS fill:#e65100,color:#fff
    style AMQ fill:#e65100,color:#fff
    style YARDI fill:#9e9e9e,color:#000
    style QB fill:#9e9e9e,color:#000
    style STRIPE fill:#9e9e9e,color:#000
    style TU fill:#9e9e9e,color:#000
    style PARTICLE fill:#2e7d32,color:#fff
    style DS fill:#9e9e9e,color:#000
    style TWILIO fill:#9e9e9e,color:#000
    style FIXR stroke:#c62828,stroke-width:3px,stroke-dasharray: 5 5

System	Pattern	Direction	Protocol
Yardi Voyager	Bidirectional Sync	Both	REST/SOAP via MuleSoft; Yardi is master for lease/financial, SF is master for work orders
QuickBooks	Event-Driven	Inbound	REST; financial transactions sync nightly for owner reporting
Stripe	Webhook	Inbound	REST webhooks to MuleSoft; payment events update Lease payment status
TransUnion	Request-Reply	Outbound	REST; triggered from lease application Flow, response updates screening status
Particle IoT	Event-Driven	Inbound	MQTT/webhooks to MuleSoft; alerts create Maintenance Requests
DocuSign	Event-Driven	Both	REST; lease sent for signing, completion callback updates Lease status
Twilio	Fire-and-Forget	Outbound	REST; triggered by work order status changes and payment reminders
FixRight Org	Bidirectional Sync	Both	MuleSoft bridges Work Orders between orgs during coexistence

Yardi sync detail: MuleSoft runs a scheduled poll every 15 minutes for lease changes in Yardi. New leases, renewals, and terminations flow to Salesforce. Work order completions in Salesforce push cost data back to Yardi for owner financial reporting. Conflict resolution: Yardi wins for lease/financial fields; Salesforce wins for maintenance/operational fields.

IoT flow: Particle publishes sensor events to MuleSoft via webhook. MuleSoft evaluates alert thresholds. Water leak alerts immediately create an Emergency Maintenance Request in Salesforce and trigger Twilio SMS to the property manager and assigned technician. HVAC anomalies create Standard-priority preventive work orders.

Artifact 5: Identity & SSO

• Internal employees (950): Google Workspace SAML 2.0 SSO. Google Directory API syncs user provisioning (create, deactivate). Google groups map to Salesforce permission set groups for regional access.
• Tenant portal (45,000): Salesforce Identity with self-registration. Email verification + password. MFA optional (SMS via Twilio). No SSO federation — tenants use Salesforce credentials.
• Owner portal (300): Salesforce Identity with invitation-based registration. MFA required (TOTP app). Owners managing multiple properties use a single login mapped to their Owner Account.
• FixRight technicians (150): During coexistence, technicians authenticate to FixRight org via existing credentials. At migration, JIT provisioning on first Google Workspace SSO login after accounts are created in Google.
• Field Service mobile: Salesforce Mobile app with certificate-based device trust for company-provided tablets. BYOD personal phones use standard SSO + mobile MFA.

Artifact 6: Data Migration Strategy

Phase 1 — Core Platform + Field Service (Months 1-7):

1. Deploy global data model: Property hierarchy (Owner > Property > Building > Unit), Work Order extensions, Sensor Device objects (months 1-3)
2. Yardi initial sync: Load 12,000 properties, 45,000 tenant records, active leases via MuleSoft bulk job. Yardi IDs stored as external keys for ongoing sync.
3. FixRight Work Order history: Export 3 years of completed work orders from SQL Server backup (ServiceTitan) + current FixRight org. Load as read-only historical records. ~85,000 records total.
4. Establish MuleSoft Yardi bidirectional sync and validate 30 days of parallel data.
5. Field Service go-live: 150 technicians begin using HNPG org for HNPG-assigned work orders (month 7). MuleSoft bridges new assignments to FixRight org for external client work.

Phase 2 — Portals (Months 5-12):

6. Tenant portal build and load test. Migrate tenants in waves: 5,000 pilot (month 8), 20,000 (month 9), remaining 20,000 (month 10). PHP portal remains active during parallel run.
7. Owner portal: 300 owners onboarded manually by account managers. Dashboard configuration per owner tier.
8. PHP portal decommissioned after 30-day parallel run with zero critical issues (month 11-12).

Phase 3 — Smart Building + Analytics (Months 10-16):

9. IoT integration for 120 smart properties. Sensor Device records created, Particle webhook configured.
10. CRM Analytics dashboards for regional managers, owners, and executives.

FixRight org migration (Month 12-14):

11. External contracts expire. FixRight accounts/contacts merged or archived. 150 technician users provisioned in HNPG org via Google Workspace. FixRight org decommissioned.

Artifact 7: Governance

Architecture Review Board (ARB): Bi-weekly. VP Technology (chair), FixRight GM, SI lead, integration lead. Reviews data model changes, integration modifications, and security changes.

Change Type	Approval	Lead Time
Data model / object changes	ARB	2 sprints
Integration changes	ARB + integration lead	2 sprints
Portal configuration	VP Technology	1 sprint
Field Service config	FixRight GM + ARB	1 sprint
Emergency fixes (P1)	VP Technology	Same day

Standards: API naming: HNPG_[Domain]_[Object]_[Purpose]. Apex: 85% code coverage minimum. All integrations through MuleSoft — no direct Apex callouts to external systems. Flow-first for automation; Apex only when Flow cannot meet the requirement.

Portal governance: Tenant-facing changes require UX review and load testing before deployment. Owner-facing financial data changes require VP Finance sign-off.

Artifact 8: Environment Strategy

Environment	Purpose	Refresh
Full Copy Sandbox	UAT + Performance testing (45K tenant load simulation)	Monthly
Partial Copy — Main	Sprint UAT, portal testing	Bi-weekly
Partial Copy — Field Service	FS mobile testing, offline scenarios	Bi-weekly
Developer Sandbox (x3)	Core / Integration / Portal teams	Sprint start
Developer Pro Sandbox	SI Partner	Sprint start

CI/CD: Salesforce CLI + GitHub + GitHub Actions. Branch strategy: main (production), release/* (UAT), feature/* (dev). Promotion: Dev Sandbox > Partial Copy > Full Copy > Production. Automated PMD scan + unit test execution on every PR.

Portal load testing: Full Copy sandbox with synthetic 45K tenant dataset. k6 load tests simulate 5,000 concurrent logins, 1,200 maintenance request submissions, and 300 owner dashboard refreshes.

Artifact 9: Phased Delivery Roadmap

gantt
    title HomeNest Property Group — 18-Month Delivery
    dateFormat YYYY-MM
    axisFormat %b %Y

    section Phase 1 — Core + Field Service
    Data model + org setup              :p1a, 2026-05, 3M
    MuleSoft + Yardi integration         :p1b, 2026-05, 4M
    Field Service configuration          :p1c, 2026-07, 3M
    FixRight bridge (MuleSoft)           :p1d, 2026-08, 2M
    Field Service Go-Live               :milestone, m1, 2026-11, 0d

    section Phase 2 — Portals
    Tenant portal build                  :p2a, 2026-09, 3M
    Owner portal build                   :p2b, 2026-10, 3M
    Tenant migration waves               :p2c, 2026-12, 3M
    PHP portal decommission              :milestone, m2, 2027-04, 0d

    section Phase 3 — Smart Building
    IoT integration (120 properties)     :p3a, 2027-02, 3M
    CRM Analytics dashboards             :p3b, 2027-03, 3M
    Smart Building Go-Live              :milestone, m3, 2027-06, 0d

    section Cross-Cutting
    FixRight org migration               :cc1, 2027-04, 3M
    Training + change management         :cc2, 2026-05, 14M
    Yardi ongoing sync validation        :cc3, 2026-07, 12M

Sequencing rationale: Field Service first because 150 technicians are the most operationally impacted group and FixRight bridge must be established early. Portals start month 5 to overlap with Field Service UAT — different teams, no dependency. IoT is last because it only affects 120 properties today and has no blocking dependency. FixRight org migration at month 12-14 after external contracts expire.

Governance & DevOps

Environment Promotion Flow

flowchart LR
    DEV1[Developer Sandbox\nCore / Data Model] --> PC_MAIN[Partial Copy — Main\nSprint UAT + Portal]
    DEV2[Developer Sandbox\nIntegration Team] --> PC_MAIN
    DEV3[Developer Sandbox\nPortal Team] --> PC_MAIN
    DEVPRO[Developer Pro\nSI Partner] --> PC_MAIN
    PC_FS[Partial Copy — FS\nField Service + Offline] --> FC[Full Copy\nUAT + Performance\n45K Tenant Load]
    PC_MAIN --> FC
    FC --> PROD[Production]

    FB1[Feature: Yardi\nBidirectional Sync] --> DEV2
    FB2[Feature: Tenant\nPortal UX] --> DEV3
    FB3[Feature: FS Mobile\nOffline Config] --> PC_FS
    FB4[Feature: IoT\nSensor Alerts] --> DEV2

Branching Strategy

HNPG has three delivery teams (core platform, portals, field service) with staggered go-lives over 18 months. The branching model supports long-running phase branches alongside sprint-level feature development.

Branch	Purpose	Merge Target
main	Production — deployed code only	N/A
release/phase-1-fs, release/phase-2-portals, release/phase-3-iot	Release stabilization per major go-live	main
develop	Integration branch for all teams	release/*
feature/HNPG-[ticket]-[description]	Individual feature work	develop
hotfix/HNPG-[ticket]-[description]	Production emergency fixes (P1 maintenance escalations)	main + develop

Merge cadence: Feature branches merge to develop via PR with 1 required reviewer. Portal changes require additional UX review. develop merges to the active release/* branch at sprint boundaries (2-week sprints). Hotfix branch exists specifically for emergency maintenance escalation issues that affect tenant safety (water leaks, gas leaks).

Sandbox Strategy

Sandbox	Type	Purpose	Refresh Cadence	Data Seeding
HNPG-DEV-CORE	Developer	Core data model, sharing rules, territory setup	Sprint start	Minimal: 100 properties across 3 regions, 500 units, 200 tenants, 10 owners
HNPG-DEV-INT	Developer	MuleSoft integration testing (Yardi, Stripe, Particle IoT)	Sprint start	Minimal: Yardi-mapped properties with external IDs, mock IoT devices
HNPG-DEV-PORTAL	Developer	Tenant and owner portal development (Experience Cloud)	Sprint start	Minimal: 50 tenant portal users, 10 owner portal users, sample lease data
HNPG-SI	Developer Pro	SI partner team — portal customization, analytics	Sprint start	Same as portal dev + additional sample financial data for owner dashboards
HNPG-INT	Partial Copy (Main)	Sprint UAT, portal testing, sharing model validation	Bi-weekly	Partial: 2,000 properties, 5,000 tenants, all 6 regions, 50 owners, 500 work orders
HNPG-FS	Partial Copy (FS)	Field Service mobile testing, offline scenarios, dispatch	Bi-weekly	Partial: 500 properties with GPS coordinates, 50 technicians, 200 open work orders, mock sensor devices
HNPG-UAT	Full Copy	UAT + performance testing with full tenant load simulation	Monthly	Full copy: 12K properties, 45K tenants, 300 owners, 5K work orders, IoT sensor data for 120 properties

Data seeding notes: Portal load testing requires synthetic 45,000 tenant accounts with realistic login patterns. The Full Copy sandbox receives a post-refresh data masking script that anonymizes tenant PII (names, emails, phone numbers) while preserving data relationships for testing. Owner financial data is masked but retains realistic dollar ranges for dashboard validation. Yardi external IDs are preserved across sandbox refreshes to maintain integration testing continuity.

Testing Strategy

Test Type	Coverage Target	Scope	Automation
Unit tests (Apex)	85% minimum (HNPG standard)	Sharing model enforcement, territory assignment, lease lifecycle, owner approval workflows, IoT alert processing	Apex tests run on every PR via GitHub Actions
Integration tests	All 8 external systems + FixRight org bridge	Yardi bidirectional sync (lease changes + work order costs), Stripe payment webhooks, TransUnion screening request-reply, Particle IoT sensor alerts, DocuSign lease signing callbacks, Twilio SMS dispatch, FixRight work order bridge	MuleSoft MUnit tests; run before release branch merge
Performance / Load tests	5,000 concurrent tenant logins; 1,200 maintenance requests/hour; 300 owner dashboard refreshes	Tenant portal concurrent access, maintenance request submission throughput, owner dashboard rendering with financial roll-ups, Field Service mobile sync performance	k6 load tests against Full Copy sandbox; run before each go-live
Offline / Field tests	150 technicians, zero-connectivity scenarios	Field Service mobile: create work order, capture photos, record parts/time, obtain signature — all offline. Sync on reconnect with conflict resolution	Manual testing in Partial Copy FS sandbox with airplane mode on test devices
UAT	All 5 user populations	Tenant portal end-to-end, owner approval workflow, regional manager territory isolation, technician work order lifecycle, leasing agent application-to-move-in flow	Manual test scripts with business stakeholders per population
Security / Sharing tests	All 5 populations verified for zero lateral visibility	Tenant A cannot see Tenant B data; Owner X cannot see Owner Y portfolio; Regional Manager TX cannot see AZ properties; Technician sees assigned work orders only; Leasing agent sees assigned properties only	Automated sharing verification scripts (Apex test class that asserts [SELECT ... WITH SECURITY_ENFORCED] returns expected row counts per user context)

Center of Excellence & Ongoing Governance

HNPG Platform CoE (established Phase 1, month 2):

• CoE lead: VP Technology (Raj Mehta) — sponsors; day-to-day led by senior Salesforce admin
• Members: 3 Salesforce admins, 2 developers (internal), SI architect (advisory through month 18), integration lead, FixRight IT liaison (2 people)
• Responsibilities: Approve all data model changes, review sharing rule modifications, manage portal release process, coordinate FixRight org bridge changes, oversee IoT scalability
• Release cadence: Production deployments bi-weekly (sprint boundaries). Portal-facing changes require additional UX review + load test pass. Emergency fixes (P1 maintenance — tenant safety): same-day deployment with VP Technology approval.
• Portal governance: Tenant-facing changes require UX review, accessibility check, and load test before deployment. Owner-facing financial data changes require VP Finance (Michelle Park) sign-off. Portal downtime windows communicated 48 hours in advance.
• FixRight transition governance: Months 1-12: FixRight GM (Tanya Brooks) approves all Field Service configuration changes. Joint ARB reviews for MuleSoft bridge modifications. Month 12-14: FixRight org migration plan reviewed by ARB at months 10, 11, 12 checkpoints. Technician user provisioning rehearsed in Full Copy sandbox before production cutover.
• Post-program maintenance: SI partner transitions to 15-hour/month managed services retainer for 6 months. Knowledge transfer sessions recorded. Internal team of 3 admins + 4 developers handles BAU. FixRight IT staff (2 people) integrated into HNPG IT team.
• IoT scalability governance: Smart building expansion from 120 to 2,000+ properties managed via IoT onboarding playbook. Each new property batch (50-100 properties) tested in Partial Copy FS sandbox before production sensor registration. Particle webhook throughput reviewed quarterly.

Identity & SSO Flow

Internal Employee SSO (SAML 2.0)

sequenceDiagram
    participant User as HNPG Employee (950)
    participant Browser as Browser
    participant Google as Google Workspace<br/>(Corporate IdP)
    participant SF as Salesforce

    User->>Browser: Navigate to Salesforce
    Browser->>SF: Request login page
    SF->>Browser: Redirect to Google (SP-Initiated SSO)
    Browser->>Google: SAML AuthnRequest
    Google->>Google: Authenticate (password + MFA)
    Google->>Browser: SAML Response with Assertion
    Note over Google,Browser: Assertion contains: email,<br/>region (TX/AZ/CO/NV/CA/FL),<br/>department, Federation ID
    Browser->>SF: POST SAML Assertion to ACS URL
    SF->>SF: Match Federation ID to User record
    SF->>SF: Assign territory-based permissions<br/>via Google group → Permission Set Group
    SF->>Browser: Session established

IdP: Google Workspace (existing for all 950 employees). Google Directory API syncs user lifecycle events (hire, terminate, transfer) to Salesforce. Google groups map to Salesforce permission set groups segmented by region and role: HNPG-TX-RegionalMgr, HNPG-AZ-LeasingAgent, HNPG-FieldService-Supervisor, etc.

MFA: Enforced at Google Workspace level for all internal users. Satisfies Salesforce MFA requirement via federated identity exception.

Tenant Portal Authentication

sequenceDiagram
    participant Tenant as Tenant (45,000)
    participant Browser as Mobile/Desktop Browser
    participant EC as Experience Cloud<br/>Tenant Portal
    participant SF as Salesforce Identity

    Tenant->>Browser: Navigate to tenant portal
    Browser->>EC: Login page
    alt New Tenant — Self-Registration
        Tenant->>EC: Click "Create Account"
        EC->>SF: Self-registration flow
        SF->>SF: Verify email matches<br/>Yardi tenant record
        SF->>Tenant: Email verification link
        Tenant->>SF: Click link, set password
        SF->>SF: Create Community user<br/>(Customer Community Plus license)
        SF->>Browser: Portal session
    else Existing Tenant — Login
        Tenant->>EC: Email + Password
        EC->>SF: Verify credentials
        SF->>SF: Optional SMS MFA via Twilio
        SF->>Browser: Portal session<br/>(scoped to tenant's unit + lease)
    end

Identity approach: Salesforce Identity with self-registration. Email addresses matched against Yardi-synced tenant records during registration to prevent unauthorized signups. No SSO federation — tenants use Salesforce credentials because they have no shared enterprise IdP.

MFA: Optional SMS-based MFA (via Twilio). Not mandatory for tenants because it creates adoption friction for the 72% mobile user base. Encouraged for tenants who enable autopay.

Owner Portal Authentication

sequenceDiagram
    participant Owner as Property Owner (300)
    participant Browser as Browser
    participant EC as Experience Cloud<br/>Owner Portal
    participant SF as Salesforce Identity

    Owner->>Browser: Navigate to owner portal
    Browser->>EC: Login page
    Owner->>EC: Email + Password
    EC->>SF: Verify credentials
    SF->>SF: MFA challenge (TOTP app required)
    Owner->>SF: TOTP code
    SF->>SF: Verify MFA
    SF->>SF: Load Partner Community session<br/>(scoped to owned properties)
    SF->>Browser: Owner dashboard<br/>(portfolio view)

Identity approach: Invitation-based registration only. Account managers send portal invitations to verified property owners. No self-registration to prevent unauthorized access to financial data.

MFA: Mandatory TOTP (authenticator app) for all owner portal users. Financial data visibility (property P&L, rent collection, maintenance spend) requires higher security than tenant portal.

FixRight Technician Authentication (Coexistence + Migration)

sequenceDiagram
    participant Tech as Technician (150)
    participant Device as Mobile Device<br/>(iOS/Android)
    participant FixOrg as FixRight Org<br/>(Months 1-12)
    participant Google as Google Workspace
    participant HNPGOrg as HNPG Org<br/>(Month 12+)

    alt During Coexistence (Months 1-12)
        Tech->>Device: Open Salesforce Mobile
        Device->>FixOrg: Login with existing<br/>FixRight credentials
        FixOrg->>Device: Session (FixRight work orders)
        Note over Device,FixOrg: HNPG work orders bridged<br/>via MuleSoft from HNPG org
    else After Migration (Month 12+)
        Tech->>Device: Open Salesforce Mobile
        Device->>Google: Google Workspace SSO<br/>(JIT provisioning on first login)
        Google->>Google: Authenticate + MFA
        Google->>HNPGOrg: SAML Assertion
        HNPGOrg->>HNPGOrg: Create/match user via JIT
        HNPGOrg->>Device: Session (all HNPG work orders)
    end

Migration identity plan: At month 12, FixRight technicians are provisioned in Google Workspace (HNPG corporate IdP). On first Salesforce login via Google SSO, JIT (Just-In-Time) provisioning creates their HNPG org user with Field Service license and appropriate permission set group. Company-provided tablets use certificate-based device trust. BYOD personal phones use standard SSO + mobile MFA.

Integration Error Handling

Integration	Pattern	Retry Strategy	Dead Letter Queue	Monitoring & Alerts	Fallback (Extended Outage)
Yardi Voyager	Bidirectional poll (15-min) via MuleSoft	3 retries, exponential backoff (30s, 2min, 10min). If all fail, queued for next 15-min poll cycle	Anypoint MQ DLQ for failed lease/financial records. Records flagged with YardiSyncError__c = true in Salesforce	PagerDuty alert to integration lead if 2 consecutive poll cycles fail. Daily Yardi sync health dashboard for VP Technology	Salesforce operates with last-synced lease data. Work order creation continues uninterrupted (SF is master for maintenance). Financial data on owner portal shows “last updated” timestamp. Manual Yardi reconciliation triggered within 4 hours
QuickBooks Enterprise	Batch nightly via MuleSoft	Full retry next nightly cycle. Individual transaction failures: 2 retries with 30s interval	Failed financial transactions stored in Anypoint MQ DLQ. VP Finance notified of any failed owner distribution records	Email alert to VP Finance if nightly batch fails. Individual transaction failures aggregated in daily error report	Owner financial statements show stale data with “as of” date. AP/AR processing continues in QuickBooks independently. Manual reconciliation after outage resolution
Stripe	Inbound webhooks via MuleSoft	3 retries at MuleSoft layer (1s, 10s, 60s). Stripe natively retries webhook delivery for up to 72 hours	Failed payment events in Anypoint MQ DLQ. Payment failure events (declined cards) escalated immediately to subscriber ops	PagerDuty alert if payment webhook failure rate exceeds 5% in any 30-minute window. Real-time Stripe dashboard monitored by finance team	Payment status not updated in Salesforce. Dunning workflows delayed. Stripe continues processing payments independently — no revenue loss. Reconciliation batch runs on outage recovery
TransUnion SmartMove	Request-reply (synchronous) via MuleSoft	2 retries with 5s interval. If TransUnion unavailable, screening request queued	Pending screening requests stored in Salesforce custom queue (Screening_Request__c with Status = Pending)	Alert to Director of Leasing if screening unavailable for >30 minutes during business hours	Lease application process pauses at screening step. Leasing agents informed via in-app notification. Applications queue and auto-submit when TransUnion returns. No manual workaround (regulatory requirement — cannot skip screening)
Particle IoT	Inbound webhooks (MQTT/REST) via MuleSoft	3 retries with 1s interval for alert-type events. Non-alert telemetry: no retry (acceptable data loss)	Emergency alerts (water leak, HVAC failure) stored in DLQ with immediate escalation. Telemetry data loss acceptable for non-alert events	PagerDuty alert to Head of Smart Building for any failed emergency sensor alert. Weekly telemetry data quality report for non-critical sensors	Emergency alerts: fallback to direct SMS notification from Particle platform to property manager (configured as backup channel in Particle Cloud). Preventive maintenance work orders delayed until IoT connectivity restores
DocuSign	Event-driven callbacks via MuleSoft	3 retries with exponential backoff (5s, 30s, 5min). DocuSign natively retries callbacks	Failed signing callbacks stored in Anypoint MQ DLQ. Lease status not updated until callback processed	Alert to leasing operations if signing callback pending >2 hours	Lease status shows “Signing in Progress” until callback received. Leasing agents can manually check DocuSign dashboard and update status. No impact on tenant — signing continues in DocuSign
Twilio (SMS)	Fire-and-forget outbound via MuleSoft	2 retries with 5s interval. Twilio handles delivery retries to carrier	Failed SMS logged to Error_Log__c. No DLQ — SMS is non-critical notification	Daily SMS delivery report reviewed by ops. Alert only if failure rate exceeds 10% for maintenance notifications	Notifications delayed. Tenants and technicians do not receive SMS updates. In-app portal notifications serve as primary fallback. Email notifications as secondary fallback
FixRight Org	Bidirectional work order sync via MuleSoft	3 retries with exponential backoff (5s, 30s, 5min). Both create and completion sync retried independently	Failed work order syncs in Anypoint MQ DLQ. FixRight GM notified of any sync failure affecting active dispatches	Real-time sync dashboard monitored by integration lead. PagerDuty alert if any HNPG-originated work order fails to reach FixRight org within 15 minutes	HNPG dispatchers call FixRight dispatch directly for urgent work orders. Non-urgent work orders queue in DLQ. Manual reconciliation required on recovery. During extended outage (>4h), FixRight dispatchers access HNPG org directly via temporary read-only login

Reporting Domain Note

Reporting is a significant domain in this scenario (Req 24-27) spanning four distinct dashboards for four audiences. Regional manager dashboards use territory-filtered reports with roll-up summary fields from the Property hierarchy. Owner dashboards leverage Partner Community analytics with sharing-scoped data. Maintenance operations dashboards use Field Service standard reporting objects (Service Appointment, Work Order). Executive dashboards use CRM Analytics for cross-object joins that standard reports cannot handle (e.g., revenue per unit requires Property + Lease + Payment joins). All dashboards respect the five-population sharing model — a dashboard shared across roles only surfaces data the viewer is authorized to see.

Presentation Strategy

In 30 minutes, go deep on two decisions: (1) the five-population sharing model — this is the hardest architectural problem in this scenario, (2) the multi-org coexistence and migration path. Cover portals and Field Service at supporting level. IoT is a brief mention.