Case Study 6: HomeNest Property Group - Worked Solution

Work in Progress

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

Reference Solution

This page compiles a worked answer for full-board study use. Compare the structure and trade-offs against your own attempt rather than treating it as the only acceptable design.

Solution Snapshot

Field	Detail
Open after	Scenario Paper
Difficulty	Intermediate
Primary pressure areas	Security, Field Service, Integration, and Multi-org Strategy
Study role	Worked solution and artifact reference
Core frameworks	9 Essential Artifacts + Five-Finger Method
Related pages	Case Study Overview, Presentation Notes, Q&A Preparation

Only Open After Your Own Attempt

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

Assumptions

1. Single org for HNPG with 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. Rejected Salesforce-to-Salesforce (S2S) because it is retiring; MuleSoft is already in the stack and provides better monitoring, error handling, and transformation.
2. Sales Cloud + Service Cloud + Field Service + Experience Cloud (formerly Community 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. Eight 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 use the Field Service mobile app with Field Service Mobile Settings controlling offline data priming. 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 grant access to the tenant’s own Unit, Lease, Maintenance Request, and Work Order records via a Primary_Tenant_Contact__c Lookup(Contact) field on each of those objects, populated when a lease activates. Customer Community Plus adds role-based sharing, sharing rules, and Apex managed sharing on top of basic Customer Community, which is required to support the Lease and Payment access model (basic Customer Community does not support sharing rules). At 45,000 users, Customer Community Plus Login licensing is the target pricing model: if monthly active login rate stays under 30%, login-based pricing materially beats per-member pricing.
• Owner Portal: Customer Community Plus licenses for 300 owners. Each owner is modeled as a Contact under an Account with Record Type “Owner Portfolio” (IsCustomerPortal = true). The owner user record is created from that Contact. Owners see their properties through criteria-based sharing rules matching Property.Owner_Account__c = $User.AccountId, plus implicit sharing from Account to child Contacts for tenant visibility. Customer Community Plus is used instead of Partner Community because Partner Community is priced for B2B channel sales (Lead, Opportunity, Campaign) that owners do not need, while Customer Community Plus provides the roles and sharing rules on custom objects at a lower effective price point for the 300-user population.

Rejected a single portal with role-based views because tenant and owner data models, financial-data sensitivity, and session timeout requirements are fundamentally different. Rejected basic Customer Community for tenants because the per-unit access pattern spans multiple custom objects (Unit, Lease, Maintenance Request, Work Order, Payment) and the basic license does not support sharing rules on Lease and Payment, forcing every object to ship its own Sharing Set plus Apex-managed sharing to keep the model consistent — Customer Community Plus collapses that complexity into native sharing rules. Rejected Partner Community for owners because the B2B sales object access (Lead, Opportunity, Campaign) is unused cost and the Partner role hierarchy does not automatically scope custom Property records without a criteria-based rule anyway.

Decision 2: Five-Population Sharing Model (D2)

Population	License	OWD on Property	Visibility
Regional Managers	Sales + Service Cloud (internal)	Private	Criteria-based sharing rules on Property by Region (6 state regions)
Leasing Agents	Sales Cloud (internal)	Private	Criteria-based sharing rules on Property by assigned properties
Technicians	Field Service Mobile user license (internal)	Private	Work Order assignment-based sharing; criteria-based Property sharing by Region for property access info
Tenants (45K)	Customer Community Plus (Login)	Private	Sharing Set on Unit/Lease/Maintenance Request/Work Order via Primary_Tenant_Contact__c Lookup(Contact)
Owners (300)	Customer Community Plus (Member)	Private	Criteria-based sharing rules on Property where Owner_Account__c = $User.AccountId

Property hierarchy: Property is Private OWD. Building inherits via Controlled by Parent (M-D to Property). Unit uses a Lookup to Building with Private OWD rather than M-D, because Controlled by Parent on Unit would cause a Sharing Set on Property to expose every unit under that property to any tenant, violating per-unit isolation.

Per-unit tenant isolation: A custom field Primary_Tenant_Contact__c (Lookup to Contact) on Unit holds the current lease holder’s portal Contact. A Flow populates this field when a Lease activates and clears it when the Lease terminates, so a Sharing Set on Unit resolving through that Contact gives the tenant access only to their current unit. For multi-tenant leases (roommates, co-signers, family members on one lease), each additional tenant receives a Contact record with a Lookup to the same Account (“Residential Tenants - {Building}”) and a parallel Primary_Tenant_Contact__c entry maintained by Apex Managed Sharing, so all tenants listed on the lease gain portal access to the same Unit through the Sharing Set.

Lease, Maintenance Request, Work Order, Payment access: Each object carries its own Primary_Tenant_Contact__c Lookup(Contact) populated by the same Lease activation Flow. Sharing Sets on Lease, Maintenance Request, and Work Order grant the tenant access through that Contact lookup. Payment records inherit access via a criteria-based sharing rule available to Customer Community Plus licenses, keyed on the same tenant Contact. This replaces the 4-level M-D chain (Property > Building > Unit > Lease) that would exceed the 3-level custom M-D platform limit, and keeps per-unit isolation explicit on each object.

Internal visibility: Property uses criteria-based sharing rules by Region (not Enterprise Territory Management — ETM only supports Account, Opportunity, Case, and Lead, not custom objects). Work Order is a standard object with Private OWD and criteria-based sharing rules by Region for regional managers plus assignment-based sharing for the specific technician assigned. Service Appointment is a standard Field Service object with Private OWD — it cannot use Controlled by Parent because it is a standard object, not a custom detail. Field Service’s predefined sharing behavior shares Service Appointments with the assigned Service Resource automatically; regional manager access flows from role hierarchy plus Work Order criteria-based rules. 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 (by S3 URL reference, not binary), and time back to HNPG org

At month 12, FixRight external contracts expire. Technician users migrate to HNPG org with Field Service Mobile licenses. FixRight org decommissioned. MuleSoft bridging chosen over the retiring Salesforce-to-Salesforce (S2S) feature because MuleSoft is already in the stack and provides better monitoring, error handling, and transformation. Salesforce Connect was considered as the S2S successor but rejected because it requires OData endpoints on the source org (not natural for standard Work Order objects) and does not support the Platform Event-driven write path needed for bidirectional sync — MuleSoft’s existing Yardi investment and error handling mature faster into the FixRight use case.

Cross-org data liability and audit trail: Because the FixRight org still serves external clients during coexistence, every HNPG work order that crosses the bridge needs an unambiguous audit record in the HNPG org regardless of where the work is actually performed. The HNPG org is treated as the system of record for all HNPG-related access events. MuleSoft writes a Cross_Org_Access_Log__c record in HNPG for every FixRight action on a bridged work order (assigned, updated, completed, photo uploaded, signature captured) with the acting FixRight user ID, timestamp, and original FixRight event ID. Smart lock entry/exit events from Particle correlate to these log entries via Work Order ID, so the HNPG audit trail reflects actual unit entry even when the authenticating user lived in a different org. This log is exported to the S3 archive alongside Event Monitoring data for 7-year retention. Tenant PII never flows across the bridge — only the tenant’s first name, unit number, and a pseudonymous reference token are passed to FixRight; full tenant contact details stay in the HNPG org and render via a MuleSoft experience API when a FixRight technician opens the work order detail. CCPA deletion requests during coexistence: the HNPG compliance team generates the deletion scope in the HNPG org, MuleSoft forwards an anonymization directive to the FixRight org referencing the pseudonymous token, and FixRight purges its local copy. Because no PII ever entered the FixRight org, the deletion scope in FixRight is limited to work order metadata and access logs that reference the token, not raw personal data.

Artifact 1: System Landscape

Figure 1. System landscape for HomeNest Property Group showing a single Salesforce org combining leasing, maintenance, Field Service, and two Experience Cloud portals, connected via MuleSoft to eight external systems including Yardi Voyager as the lease-of-record, Particle IoT for 4,800 smart devices, and a 12-month MuleSoft bridge to the FixRight org during technician coexistence before full org migration.

Artifact 2: Data Model

Figure 2. Data model for HomeNest Property Group built around a property hierarchy (Owner Account, Property, Building via M-D, then Unit via Lookup with Private OWD for per-unit tenant isolation). Owner is a standard Account with Record Type “Owner Portfolio”; owner portal users are Contacts under that Account with IsCustomerPortal = true so Experience Cloud can create User records from them. Tenants are Contacts under a “Residential Tenants - {Building}” Account, with a Primary_Tenant_Contact__c Lookup on Unit/Lease/Maintenance Request/Work Order/Payment that Sharing Sets resolve through for per-unit access. Lease is a Lookup to Unit with Private OWD to stay within the 3-level M-D platform limit and enable independent sharing. Work Order and Service Appointment are Private OWD standard Field Service objects (neither supports Controlled by Parent because they are standard, not custom detail). Sensor Event stores only actionable alerts in Salesforce; raw telemetry is streamed to the external data lake directly from MuleSoft to meet Req 29 scale-without-rearchitecture at 80K-device target.

• Owner Account and Owner Contact: Owner is a standard Account with Record Type “Owner Portfolio” and IsCustomerPortal = true. Each owner user is a Contact under that Account. Experience Cloud creates the owner user from the Contact, which is the only supported path for portal user provisioning — Salesforce cannot create a Customer Community or Partner Community user from a standalone custom object.
• Property hierarchy: M-D from Property to Building (Controlled by Parent), then Lookup from Building to Unit (Private OWD). This breaks the M-D chain at Unit so a Sharing Set on Unit can isolate tenants to their own unit without propagating to siblings.
• Per-unit tenant isolation: Primary_Tenant_Contact__c Lookup(Contact) on Unit is populated by Flow when a Lease activates and cleared when it terminates. Sharing Sets on Unit, Lease, Maintenance Request, Work Order, and Payment resolve through this Contact field so the tenant sees only records tied to their current unit. For multi-tenant leases, additional tenants are added to the lease via Apex Managed Sharing parallel rows.
• Lease is a Lookup to Unit with Private OWD. A M-D chain of Property > Building > Unit > Lease would be 4 levels, exceeding the platform limit of 3 custom M-D levels. YardiLeaseId is the external key for sync.
• Work Order uses the standard Field Service object with Private OWD and a custom Property__c Lookup to Property. Technician access is via assignment-based sharing; regional manager access is via criteria-based sharing rules keyed on the Property__c Region (looked up from Property via formula field on Work Order). Tenant access is via a Sharing Set that follows Primary_Tenant_Contact__c. Property access instructions (access codes, gate entry) are duplicated onto Work Order as fields so technicians do not need record access to the parent Property. Extended with custom fields for parts cost, completion photos, and owner approval status.
• Service Appointment is a standard Field Service object with Private OWD. Standard objects cannot be on the detail side of a custom M-D relationship, so Controlled by Parent is not available. Field Service’s built-in sharing shares Service Appointments with their assigned Service Resource; regional managers inherit through role hierarchy; Work Order cross-references carry forward via the native Work Order -> Service Appointment lookup.
• Sensor Device and Sensor Event: Sensor Device is a lightweight registry (~4,800 rows today, ~80,000 at 2,000-property scale). Raw Particle telemetry (45,000 events/day today, ~765,000/day at target) is not stored in Salesforce at all. MuleSoft streams raw telemetry directly to the external data lake (S3 or Snowflake) and publishes only actionable alerts (water leak detected, HVAC failure, smart lock entry correlated to a scheduled Work Order) as Sensor Event records in Salesforce. At 2% alert-to-telemetry ratio, Sensor Event stays under 1,000 records/day even at full scale, which is what meets Req 29’s “scale without architectural rework” promise — the architecture for 120 properties is identical to the architecture for 2,000+ properties, with the data lake absorbing the volume growth.

Artifact 3: Role Hierarchy & Sharing Model

Figure 3. Role hierarchy for HomeNest Property Group with six state-based regional branches under VP Property Management (Texas, Arizona, Colorado, Florida, Nevada, California), Field Service technician supervisors under VP Technology (post-migration at month 12), and VP Finance with FLS via Permission Set Groups limiting property financial data (NOI, owner distributions) to Finance and Owner portal profiles only. External users (45,000 tenants and 300 owners) are on Customer Community Plus licenses and are not shown in the internal role hierarchy diagram; they have their own external role hierarchy underneath their respective Accounts (Owner Portfolio Accounts for owners, Residential Tenants Accounts for tenants). During the 12-month coexistence, FixRight technicians remain in the FixRight org and access HNPG work orders via MuleSoft bridge — they are not placed in the HNPG role hierarchy until migration is complete.

Object	OWD	Sharing Mechanism	Volume
Owner Account (RecordType Owner Portfolio)	Private	Account-level criteria rule; portal users created from child Contacts with IsCustomerPortal=true	~300
Owner Contact	Controlled by Parent	Implicit sharing from Owner Account to portal Contact	~300 plus delegates
Residential Tenants Account (one per building)	Private	Portal Tenants Contacts are children of these Accounts	~12K
Tenant Contact	Controlled by Parent	Implicit sharing from Residential Tenants Account	~45K
Property	Private	Custom object; criteria-based sharing rules by Region (6 regions) for internal; criteria-based rule for owners where Owner_Account__c = $User.AccountId	~12K
Building	Controlled by Parent	M-D to Property; inherits from Property	~12K
Unit	Private	Lookup to Building; Sharing Set on Unit via Primary_Tenant_Contact__c Lookup(Contact) for tenants	~12K
Lease	Private	Lookup to Unit; Sharing Set via Primary_Tenant_Contact__c for tenants; role hierarchy for internal	~45K active
Maintenance Request	Private	Lookup to Unit; Sharing Set via Primary_Tenant_Contact__c for tenants; role hierarchy for internal	~14.4K/yr
Work Order	Private	Standard object; Sharing Set via Primary_Tenant_Contact__c for tenants; criteria-based by Region for regional managers; assignment-based for technicians	~14.4K/yr
Service Appointment	Private	Standard object; Field Service native assignment-based sharing with Service Resource plus role hierarchy for supervisors	~14.4K/yr
Payment	Private	Lookup to Lease; criteria-based sharing rule on Primary_Tenant_Contact__c for tenants (enabled by Customer Community Plus); role hierarchy for Finance	~8K events/day
Sensor Device	Controlled by Parent	M-D to Property; inherits from Property	~4.8K today, ~80K at target
Sensor Event (actionable alerts only)	Controlled by Parent	Inherits from Sensor Device; raw telemetry never stored in SF	~1K actionable alerts/day max

Technician visibility: Technicians see Work Orders assigned to them (assignment-based sharing). Property access information (address, access codes, gate instructions) is duplicated onto the Work Order as fields during Work Order creation, so the technician does not need record-level access to the parent Property. Criteria-based sharing on Property by Region grants technicians read access to properties in their assigned region for navigation and history, but financial fields (NOI, owner distributions, management fee percentage) are hidden via field-level security enforced through Permission Set Groups. The technician never sees lease terms, rent amounts, or owner financials on any object.

Tenant Work Order access (Req 3): Tenants access their own Work Orders through a Sharing Set on Work Order that resolves via Primary_Tenant_Contact__c (Lookup to Contact). When a Maintenance Request creates a Work Order, Flow copies the Maintenance Request’s Primary_Tenant_Contact__c onto the Work Order, which the Sharing Set uses to grant the tenant read access. Tenants see status transitions (Received, Assigned, Scheduled, In Progress, Completed) but not technician commentary fields or internal notes, which are hidden via FLS.

Owner visibility: Owners see Properties where Owner_Account__c = $User.AccountId via a criteria-based sharing rule. Building and Sensor Device inherit through Controlled by Parent. Unit is accessed through a criteria-based rule on Building.Property.Owner_Account__c (criteria-based sharing on Customer Community Plus supports formula-field criteria). Lease and Payment reach the owner via criteria-based sharing rules referencing the same owner account. Owners do not see individual tenant PII — tenant Contact visibility is scoped via FLS so owners see unit-level rent roll data, not personal contact details.

Field-Level Security: Financial fields on Property (revenue, owner distributions, NOI) are hidden from all profiles except VP Finance, Owner portal, and Regional Manager via FLS enforced through Permission Set Groups. Restriction Rules are not used here because they control record-level visibility, not field-level access.

Compliance architecture (Req 50, 52, 53):

• Req 50 (tenant PII encrypted at rest, never stored in Salesforce): SSN and bank account numbers never land in Salesforce. TransUnion holds screening PII; Stripe holds payment account numbers. A hashed tokenized reference is all that enters Salesforce. Shield Platform Encryption is applied to the few sensitive tenant fields that must reside in Salesforce (driver license number, last four of SSN for identity verification only) using deterministic encryption so the fields support filtering in reports and list views.
• Req 52 (audit trail of access to tenant and owner financial data): Salesforce Shield Event Monitoring captures read events on Payment, Lease, Owner_Statement__c, and Property financial fields via Transaction Security Policies and EventLogFile. Native Event Monitoring retention is 30 days; with the Summer ‘24+ Event Monitoring Log File Storage add-on, retention extends to 1 year. Because Req 52 is a 7-year audit obligation for owner financial data, a nightly MuleSoft job exports EventLogFile rows to an S3 archive bucket with AWS KMS encryption and 7-year lifecycle retention. Field Audit Trail is used separately for change history (who updated a rent roll or distribution record) with up to 10 years of retention per the Field Audit Trail Standard feature.
• Req 53 (technician unit access logged with smart lock entry/exit): Particle smart lock events are correlated to Work Order assignments in MuleSoft and written as an immutable Technician_Access_Log__c record tied to the Work Order. The log captures timestamp, device ID, technician user ID, and smart lock event ID. Event Monitoring captures the corresponding Work Order read/update events. Both streams are exported to the same S3 archive for correlation and 7-year retention.

Distinguishing the three controls: Shield Platform Encryption protects data at rest so admins and backup operators cannot read sensitive fields in storage. Event Monitoring captures read and update events (who accessed what record, when) with 30-day to 1-year native retention extended via external archive for longer windows. Field Audit Trail captures the old and new values of tracked fields over time (what the record looked like on any given date) for up to 10 years. Each addresses a different question: encryption answers “who can read this data outside the app,” Event Monitoring answers “who touched this record today,” and Field Audit Trail answers “what did this record look like two years ago.”

Artifact 4: Integration Architecture

Figure 4. Integration architecture for HomeNest Property Group with MuleSoft Anypoint handling eight external system connections: Yardi Voyager as the lease master with SOAP inbound polling every 15 minutes for lease and rent events plus event-driven outbound updates from Salesforce on work order completion, Particle IoT streaming raw telemetry directly to an external data lake while publishing only actionable alerts as Sensor Event records in Salesforce (so the architecture scales from 120 to 2,000+ properties without rework), and a temporary bidirectional FixRight org bridge for work order metadata sync (photos referenced by S3 URL rather than transferred as binaries) during the 12-month coexistence period.

System	Pattern	Direction	Protocol
Yardi Voyager (inbound)	Scheduled Polling (15-min cycle)	Inbound	SOAP via MuleSoft (Yardi Voyager Web Services WSDL); Yardi is master for lease/financial
Yardi Voyager (outbound)	Event-Driven Update	Outbound	SOAP via MuleSoft; Salesforce publishes Platform Events on Work Order completion, MuleSoft pushes cost data to Yardi
QuickBooks	Scheduled Batch	Inbound	REST nightly batch via MuleSoft; financial transactions for owner reporting
Stripe	Webhook	Inbound	REST webhooks to MuleSoft; payment events update Lease payment status
TransUnion SmartMove	Asynchronous Request + Webhook Callback	Outbound then Inbound	REST POST to initiate screening (applicant consent required); TransUnion webhook callback delivers results when applicant completes their side; average end-to-end 1-24 hours
Particle IoT	Event-Driven Stream	Inbound	MuleSoft routes raw MQTT telemetry directly to external data lake; only actionable alerts (water leak, HVAC failure, correlated smart lock entry) flow into Salesforce as Sensor Event + Maintenance Request
DocuSign	Event-Driven Callback	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
Work Order Photos (Req 8)	Binary File Offload	Both	Tenants and technicians upload to Salesforce Files (Content Version); MuleSoft stores the file in S3 and persists only the S3 URL on Work Order / Maintenance Request; binaries never cross the MuleSoft bus
FixRight Org	Bidirectional Metadata Sync	Both	MuleSoft bridges Work Order metadata (not binary files); completion photos referenced by S3 URL shared between orgs

Yardi sync detail: Yardi Voyager exposes a SOAP-first Web Services interface with per-WSDL licensing (typical $25K/year per interface partner agreement). MuleSoft uses the Yardi Voyager Web Services SOAP connector to run a scheduled inbound poll every 15 minutes for lease, renewal, and termination changes. Outbound updates from Salesforce to Yardi are event-driven: when a Work Order closes, a Platform Event fires and MuleSoft pushes the cost data to Yardi in the next poll boundary. Peak cycles (first of the month when rent events spike to 500-1,000 events per cycle) are handled by bulk SOAP calls with MuleSoft Dataweave batching; API rate limits are enforced at the MuleSoft layer with backpressure to the Platform Event subscription. Conflict resolution: Yardi wins for lease/financial fields; Salesforce wins for maintenance/operational fields.

TransUnion SmartMove flow: SmartMove is asynchronous by design because the applicant must consent before credit and background data is released. The lease application Flow posts an initial screening request to TransUnion via MuleSoft (POST /screening/request). TransUnion emails the applicant a consent link. The applicant completes the consent and authorization on TransUnion’s portal. When the screening report is ready (typically minutes to hours, sometimes 24 hours for manual review), TransUnion posts a webhook callback to MuleSoft with the result. MuleSoft updates the Screening_Request__c custom object in Salesforce, which triggers the next step in the lease application Flow. The leasing agent sees the status transition from “Screening Requested” to “Screening Complete” without a synchronous wait.

Work order photos (Req 8): Tenants upload up to 5 photos at 10MB each per maintenance request (50MB peak per record). Binary files of this size do not flow through the MuleSoft bus because payload size bloats the middleware and consumes API limits. Photos are uploaded directly to Salesforce Files (Content Version) on the tenant portal; a background job offloads the file to an S3 bucket with a pre-signed URL reference persisted on the Work Order record. Cross-org sharing (HNPG to FixRight) uses only the S3 URL, not the binary itself. FixRight technicians fetch the file from S3 directly with their own signed URL, keeping MuleSoft out of the binary transfer path.

IoT flow: Particle publishes sensor telemetry via MQTT to MuleSoft. MuleSoft is the evaluation layer: raw telemetry (temperature readings, humidity, door open/close counts) streams directly from MuleSoft to the external data lake (S3 or Snowflake) and never lands in Salesforce. Only actionable alerts (water leak detected, HVAC failure threshold breached, unauthorized smart lock entry correlated to no active Work Order) are published as Sensor Event records in Salesforce, which trigger Emergency Maintenance Request creation and Twilio SMS to the property manager and assigned technician. This architecture is designed day one for the 2,000+ property target: adding properties grows the data lake, not the Salesforce storage footprint.

Artifact 5: Identity & SSO

• Internal employees (950): Google Workspace SAML 2.0 SSO as the Identity Provider; Salesforce is the Service Provider. Google Directory API syncs user provisioning (create, deactivate) to Salesforce via a MuleSoft orchestration that calls the Salesforce User REST API. Google groups map to Salesforce Permission Set Groups via a custom mapping table maintained by the IdP team: HNPG-TX-RegionalMgr group -> PSG_TX_Regional_Manager Permission Set Group, HNPG-Field-Technician group -> PSG_Field_Service_Technician, etc. The MuleSoft orchestration processes group membership changes nightly and assigns or revokes the matching Permission Set Group via the PermissionSetAssignment SObject, so IdP group changes propagate to Salesforce within 24 hours without any manual admin work.
• Tenant portal (45,000): Salesforce Identity (Experience Cloud self-registration) with email + password. The self-registration flow uses a custom Apex registration handler (extends Auth.RegistrationHandler) that runs as a dedicated integration user with the “Manage External Users” permission. The handler verifies the applicant’s email matches a Yardi-synced tenant record with LeaseStatus = Active, looks up the matching Contact under the correct “Residential Tenants - {Building}” Account, sets the Contact as Primary_Tenant_Contact__c on the tenant’s Unit, creates the User record with ProfileId = CustomerCommunityPlusLogin_Tenant, and assigns the PSG_Tenant_Portal Permission Set Group. MFA is optional at baseline; tenants who enable autopay are required to enable MFA the next time they log in. Salesforce Identity Verification supports SMS as a verification method out of the box; the default SMS provider is Salesforce’s own delivery. A separate initiative to route SMS OTPs through Twilio would require a custom OTP provider implementing the Auth.CustomOneTimePasswordDeliveryHandler interface with Named Credentials for the Twilio callout and an Apex handler for the callback — it is not a config toggle.
• Owner portal (300): Salesforce Identity with invitation-based registration only (no public self-signup). Account managers send portal invitations using Experience Cloud’s “Invite People” flow to verified Contacts under an Owner Portfolio Account. A registration handler (separate from the tenant handler) runs as an integration user, creates the User with ProfileId = CustomerCommunityPlus_Owner, assigns PSG_Owner_Portal Permission Set Group based on the Contact’s PortalRole field (primary owner, delegated manager, accountant), and sets the session policy to the stricter 15-minute timeout. MFA is mandatory using TOTP (authenticator app) because the portal surfaces financial data.
• FixRight technicians (150): During coexistence (months 1-12), technicians authenticate to the FixRight org directly with their existing credentials and never sit in the HNPG role hierarchy. At month 12 cutover, technicians are provisioned in Google Workspace first, then on their first login to the HNPG org, SAML Just-In-Time provisioning runs through a registration handler (extends Auth.SamlJitHandler). The handler runs as a dedicated integration user with “Manage Users” and “Manage Internal Users,” creates or matches the User on FederationIdentifier, sets ProfileId = FieldServiceTechnician, assigns the PSG_Field_Service_Technician Permission Set Group based on the Google group claim in the SAML assertion, and assigns the Field Service Mobile user license. Default profile for JIT is FieldServiceTechnician; unmatched group claims fall back to a read-only profile that alerts IT for manual review.
• Field Service mobile: Field Service mobile app (not the standard Salesforce Mobile App) with certificate-based device trust for company-provided tablets. Offline priming is handled through Field Service Mobile Settings for standard work order and service appointment records. For large reference datasets (property access instructions, preventive maintenance playbooks, parts catalog by region), Briefcase Builder with High Volume Priming handles the complex record-selection rules — Briefcase Builder does support Field Service mobile offline priming in current releases. The combination is Field Service Mobile Settings for per-assignment work order data, Briefcase Builder for reference data that changes less frequently. BYOD personal phones use standard Google SSO plus mobile MFA.

Artifact 6: Data Migration Strategy

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

1. Deploy global data model: Owner Accounts (Record Type “Owner Portfolio”), Residential Tenants Accounts per Building, Property hierarchy (Property, Building via M-D, Unit via Lookup), Work Order extensions, Sensor Device objects (months 1-3)
2. Yardi initial sync: Load 12,000 properties, 45,000 tenant Contacts (under Residential Tenants Accounts per building), active leases via MuleSoft bulk job. Yardi IDs stored as external keys for ongoing sync. Primary_Tenant_Contact__c backfilled on Unit, Lease, Maintenance Request, and Payment during the initial load.
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 by account managers through the invitation-based registration flow. Each owner Contact is created under the Owner Portfolio Account and mapped to the correct Owner Permission Set Group by tier (primary owner, delegated manager, accountant). Manual onboarding is feasible at 300 users; as the owner population grows beyond 600, the architecture moves to Data Loader-based bulk provisioning with email-triggered invitation links for the managed services phase.
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, MuleSoft streaming topology configured with Particle as the source, external data lake as the destination for raw telemetry, and Salesforce as the destination for actionable alerts only.
10. CRM Analytics dashboards for regional managers, owners, and executives. Licensed separately (see budget below). Security handled via CRM Analytics Security Predicates keyed on Region__c and Owner_Account__c so each dashboard respects the five-population sharing model.

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 SAML JIT. 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.

Budget Breakdown (SaaS License Costs within $3.8M)

The $3.8M program budget is split between implementation services (SI partner delivery, internal team, infrastructure) and SaaS license operating expense for the 18-month program window. License pricing uses list reference rates; negotiated discounts for a mid-sized multi-cloud commitment typically land 20-30% below list.

Line Item	Unit Price (List)	Quantity	Monthly	18-Month Total
Sales Cloud Enterprise	$165/user/mo	100 leasing + management	$16,500	$297,000
Service Cloud Enterprise	$165/user/mo	150 maintenance + ops	$24,750	$445,500
Field Service Mobile (technician license)	$165/user/mo	150 technicians	$24,750	$445,500
Field Service Dispatcher	$220/user/mo	10 dispatchers	$2,200	$39,600
Experience Cloud: Customer Community Plus Login	$6/login	45,000 tenants @ ~25% MAU, ~3 logins/mo	$20,250	$364,500
Experience Cloud: Customer Community Plus Member	$15/user/mo	300 owners	$4,500	$81,000
CRM Analytics Growth	$125/user/mo	20 internal (managers, execs, owners via embedded)	$2,500	$45,000
Shield (Platform Encryption + Event Monitoring + Field Audit Trail)	~25-30% of Salesforce base license fees	Applied to internal licenses	~$15,000	$270,000
MuleSoft Anypoint Platform	Volume-based	3 APIs + 8 system connectors	~$12,000	$216,000
SaaS License Subtotal				~$2.2M
Implementation Services (SI partner + internal team + infra)				~$1.2M
Contingency (10%)				$0.4M
Total				$3.8M

License costs dominate the 18-month operating line at roughly $2.2M, with implementation services consuming the remaining $1.2M plus the $0.4M contingency. The single largest variable is the Customer Community Plus Login license rate for 45,000 tenants — if monthly active login rate rises above 30%, the economics shift toward per-member licensing and the budget would require rebalancing out of the Phase 3 analytics scope. Shield is a fixed percentage-of-base-license add-on that enables Platform Encryption (Req 50), Event Monitoring (Req 52), and Field Audit Trail (Req 52) on the same subscription — not separately priced.

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

Figure 5. Phased delivery roadmap for HomeNest Property Group prioritizing Field Service and Yardi integration in Phase 1 to address the highest operational risk for 150 technicians and 45,000 tenants, portal build and wave-based tenant migration in Phase 2, IoT integration for 120 smart properties and analytics in Phase 3, and FixRight org decommission at months 12-14 after external contracts expire.

Sequencing rationale: Field Service first because 150 technicians are the most operationally impacted group and FixRight bridge must be established early. Portals start at month 5 to overlap with Field Service UAT. The teams are different with 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

Figure 6. Environment promotion flow for HomeNest Property Group with four developer sandboxes plus a dedicated Field Service Partial Copy for offline mobile testing, promoting through a main Partial Copy for sprint UAT to a Full Copy sandbox carrying 12,000 properties and 45,000 synthetic tenants for portal load simulation at 5,000 concurrent logins, before VP Technology approval gates production release.

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)

Figure 7. Employee SSO sequence for HomeNest Property Group using SP-initiated Google Workspace SAML 2.0 for all 950 staff, where SAML assertions carry region (TX, AZ, CO, NV, CA, FL) and department claims that map to Salesforce Permission Set Groups, with Google Directory API handling user lifecycle events so technician and leasing agent accounts are deactivated in Salesforce within minutes of a Google Workspace deprovisioning event.

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 -> PSG_TX_Regional_Manager, HNPG-AZ-LeasingAgent -> PSG_AZ_Leasing_Agent, HNPG-FieldService-Supervisor -> PSG_Field_Service_Supervisor, etc. A MuleSoft orchestration reads Google group membership nightly and calls the Salesforce User REST API and PermissionSetAssignment SObject to add or remove Permission Set Group assignments. The same orchestration handles profile default for new hires by reading the employee department claim in the SAML assertion on first login.

MFA: Mandatory at Google Workspace level for all internal users. Salesforce’s MFA requirement is satisfied when SSO is enforced through an IdP that enforces MFA, so the Google Workspace MFA policy fulfills the Salesforce obligation directly.

Tenant Portal Authentication

Figure 8. Tenant portal authentication sequence for HomeNest showing two paths: new tenants self-registering through a custom Apex registration handler that verifies email against Yardi-synced records, creates the User from the matching Contact under the correct Residential Tenants Account, sets Primary_Tenant_Contact__c on the tenant’s Unit, and assigns the Tenant Portal Permission Set Group; and existing tenants logging in with Salesforce Identity plus optional SMS MFA delivered by Salesforce Identity Verification. Every session is scoped via a Sharing Set that resolves through Primary_Tenant_Contact__c so a tenant sees only their own Unit, Lease, Maintenance Request, Work Order, and Payment records. Tenants use Customer Community Plus licenses, which support sharing sets, criteria-based sharing rules, and role-based sharing on custom objects.

Identity approach: Salesforce Identity with self-registration through a custom registration handler (Apex class extending Auth.RegistrationHandler). The handler runs as a dedicated integration user with the “Manage External Users” permission. On a registration attempt, the handler verifies the applicant’s email matches a Yardi-synced tenant Contact with an active lease, creates the User record from that Contact with ProfileId = CustomerCommunityPlusLogin_Tenant, writes the Contact ID into Primary_Tenant_Contact__c on the tenant’s Unit and related Lease/Maintenance Request/Work Order/Payment records, and assigns the PSG_Tenant_Portal Permission Set Group. No SSO federation — tenants have no shared enterprise IdP. Self-service password reset is enabled to keep support call volume below 2% of login attempts.

MFA: Optional SMS-based MFA delivered by Salesforce Identity Verification (Salesforce-hosted SMS by default, not Twilio). Not mandatory at baseline because it creates adoption friction for the 72% mobile user base. Required for tenants who enable autopay — the autopay enrollment Flow sets Require_MFA__c = true on the User and the next login prompts for SMS verification. A separate Twilio-branded OTP delivery path would require implementing a custom OTP provider (Auth.CustomOneTimePasswordDeliveryHandler), an authenticated callout via Named Credentials, and an Apex handler for the delivery callback — not part of the baseline architecture.

Owner Portal Authentication

Figure 9. Owner portal authentication sequence for HomeNest Property Group using invitation-only Salesforce Identity registration (no self-signup) with mandatory TOTP MFA, reflecting the higher security requirement for 300 property owners accessing financial data including NOI, rent collection rates, and maintenance spend across their portfolios. Each owner user is a Contact under an Owner Portfolio Account (IsCustomerPortal = true), which is the only supported Experience Cloud user provisioning path for Customer Community Plus.

Identity approach: Invitation-based registration only. Account managers send portal invitations through Experience Cloud’s “Invite People” flow to verified Contacts already created under an Owner Portfolio Account. A custom registration handler (separate from the tenant handler) runs as an integration user with “Manage External Users,” creates the User with ProfileId = CustomerCommunityPlus_Owner, assigns the PSG_Owner_Portal Permission Set Group based on the Contact’s PortalRole field (primary owner, delegated manager, accountant), and sets the session policy to the 15-minute timeout. No self-registration because unauthorized portfolio visibility would be a compliance incident.

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

FixRight Technician Authentication (Coexistence + Migration)

Figure 10. FixRight technician authentication sequence showing the two-phase transition: months 1-12 technicians authenticate to their existing FixRight org while HNPG work orders flow via MuleSoft bridge, then at month 12 after FixRight org decommission technicians switch to Google Workspace SAML on the HNPG org with JIT provisioning creating their Field Service user record on first login.

Migration identity plan: At month 12, FixRight technicians are provisioned in Google Workspace (HNPG corporate IdP) first, which places them in the HNPG-Field-Technician-{Region} group. On first Salesforce login via Google SAML SSO, a SAML JIT handler (Apex class extending Auth.SamlJitHandler) runs as a dedicated integration user, creates the User with ProfileId = FieldServiceTechnician and FederationIdentifier set to the Google Federation ID, assigns the Field Service Mobile user license, and assigns the PSG_Field_Service_Technician Permission Set Group keyed on the group claim in the SAML assertion. The default profile for unmatched group claims falls back to a read-only “HNPG_Unassigned” profile that alerts IT for manual review. Company-provided tablets use certificate-based device trust. BYOD personal phones use standard SSO plus mobile MFA.

Integration Error Handling

Integration	Pattern	Retry Strategy	Dead Letter Queue	Monitoring & Alerts	Fallback (Extended Outage)
Yardi Voyager (inbound poll + outbound event)	SOAP scheduled poll (15-min) inbound plus event-driven outbound on Work Order close, both via MuleSoft	3 retries, exponential backoff (30s, 2min, 10min). If all fail, queued for next 15-min poll cycle or the next event retry window	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	Emergency maintenance (30-min SLA): HNPG dispatcher calls FixRight dispatch directly by phone and enters the work order manually into FixRight. Non-urgent work queues in DLQ. For extended outages (>2h), a pre-provisioned HNPG-FixRight-Bridge-Ops Permission Set Group is activated via Google Workspace group assignment for a named set of FixRight dispatchers, who then JIT-provision into the HNPG org with read-only access to the Work Order dispatch queue and property access instructions only. The provisioning path is identical to the normal technician JIT flow (SAML JIT handler + group-to-PSG mapping), pre-configured and rehearsed in the Full Copy sandbox during Phase 1 so activation is a single Google Workspace group change, not a runtime design decision

Reporting Domain Note

Reporting is a significant domain in this scenario (Req 54-57) spanning four distinct dashboards for four audiences. Regional manager dashboards use criteria-based region filters with roll-up summary fields from the Property hierarchy. Owner dashboards use CRM Analytics embedded in the Customer Community Plus owner portal with CRM Analytics Security Predicates keyed on Owner_Account__c to enforce portfolio scoping. 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). CRM Analytics is licensed as a paid add-on (CRM Analytics Growth) and is included in the budget line for approximately 20 internal seats. 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 45 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.

Scoring Rubric

Criterion	Weight	What Judges Look For
Security & Sharing Model	30%	Five-population sharing model (tenants, owners, property managers, maintenance techs, acquired-org users). Each population’s access pattern explained with specific sharing mechanism. Owner portal data isolation. Tenant portal data scoping. Regional manager territory-based access
Integration Architecture	20%	Yardi Voyager bidirectional sync. QuickBooks financial integration. Stripe payments. IoT sensor webhooks. DocuSign lease signing. Multi-org coexistence with FixRight. Each endpoint with pattern, retry, DLQ, and fallback
System Architecture	20%	Multi-org acquisition strategy (coexistence vs migration path). Field Service for maintenance dispatching. Multi-portal architecture (tenant, owner, vendor). IoT smart building integration. Licensing across user populations
Data Architecture	15%	Property hierarchy data model. Lease lifecycle management. Work order and maintenance history. IoT sensor data storage. Migration plan for acquired-org data
Communication & Presentation	15%	Five-population sharing model clearly diagrammed and defended. Multi-org coexistence rationale. Field Service workflow articulated. Presentation strategy focuses on the two hardest decisions

---

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.