Case Study 6: HomeNest Property Group - Q&A Preparation

Work in Progress

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

Q&A Guide

This page compiles judge-style follow-up questions for the case study. Use it after your presentation run-through so you can test how well you defend your choices.

Q&A Snapshot

Field	Detail
Open after	Presentation Notes
Format	45-minute Q&A following a 45-minute presentation
Study role	Practice concise, defensible answers
Related pages	Case Study Overview, Scenario Paper, Worked Solution

Q&A Strategy

State your position, give the reasoning, acknowledge the trade-off, and keep answers to 1-2 minutes.

Private OWD is the foundation — no user sees anything unless explicitly granted. Tenants access their records through Sharing Sets that resolve via a Primary_Tenant_Contact__c Lookup(Contact) on Unit, Lease, Maintenance Request, Work Order, and Payment — the Sharing Set scope only grants access where the Contact lookup matches the portal user’s own Contact ID, which is a platform-enforced boundary. Owners access their records through criteria-based sharing rules keyed on Owner_Account__c = $User.AccountId, which is isolated to their own portfolio. These two mechanisms operate independently. I add automated SOQL-based sharing validation tests in CI/CD that verify a sample tenant cannot query another tenant’s records and a sample owner cannot query another owner’s records. All sharing rule changes require ARB approval before production deployment.

Q2: Why Customer Community Plus licenses for tenants instead of basic Customer Community?

The architecture needs sharing rules on Lease and Payment objects to grant criteria-based access to tenants, and basic Customer Community does not support sharing rules — only Sharing Sets. Customer Community Plus adds sharing rules, roles, and Apex managed sharing on top of Sharing Sets, which the multi-object tenant access pattern requires. At 45,000 users, the practical licensing choice is Customer Community Plus Login (priced per login, not per member) because tenant monthly active login rates are expected to stay under 30%. Login pricing at that activity level is materially cheaper than the member-based pricing, and the Plus tier gives the sharing-rule capability needed for a consistent model across Lease, Maintenance Request, Work Order, and Payment without stitching together multiple Sharing Sets plus Apex managed sharing to cover the gaps. Basic Customer Community would force every object to ship its own Sharing Set and still leave Lease and Payment needing Apex managed sharing for criteria-based access.

Q3: A leasing agent needs to see lease applications but not owner financials on the same Property record. How?

Field-level security enforced through Permission Set Groups hides financial fields (NOI, owner distributions, management fee percentage) from the leasing agent profile. The agent sees the property address, unit details, and application data but not revenue or owner-facing metrics. FLS is the correct mechanism here because we are controlling field visibility, not record access. Restriction Rules would be wrong for this purpose since they control which records a user can see, not which fields. The agent’s page layout only includes leasing-relevant sections.

Q4: What happens when a technician is assigned to a property in Region A but their supervisor is in Region B?

Work Order assignment-based sharing grants the assigned technician access to that Work Order regardless of region. The supervisor sees the Work Order through role hierarchy (VP Technology > Tech Supervisors > Technicians). Criteria-based sharing by Region on Property governs regional manager visibility, but the Field Service hierarchy under VP Technology is separate from the regional manager hierarchy under VP Property Management. There is no conflict because these are independent sharing mechanisms. The technician sees the assigned Work Order plus property access information that is duplicated onto the Work Order record itself (access codes, gate entry, physical address) — so the technician does not need to open the parent Property to complete the job. A criteria-based sharing rule on Property by Region gives technicians read access to properties in their assigned region for navigation purposes, but FLS via Permission Set Groups hides financial fields (NOI, owner distributions, rent amounts) from the technician profile. During the 12-month coexistence, FixRight technicians are not in the HNPG role hierarchy at all; they access HNPG work orders only via the MuleSoft bridge to the FixRight org.

Q5: How do you enforce the session timeout difference between tenant portal (60 min) and owner portal (15 min)?

Each Experience Cloud community has its own session settings. The tenant portal community is configured with a 60-minute session timeout to balance usability for the 72% mobile user base. The owner portal community uses a 15-minute timeout because owners access financial data (portfolio P&L, distributions, maintenance spend). These are separate community configurations on the same org - session policies do not bleed between communities. If an owner is also a tenant (unlikely but possible), they get the timeout of whichever portal they are currently logged into.

Identity and SSO

Social login would reduce friction for tenants, but it introduces a dependency on a third-party IdP that HNPG does not control. If Google changes their OAuth policies or has an outage, 45,000 tenants cannot log in. More importantly, tenant self-registration must validate email addresses against Yardi-synced tenant records to prevent unauthorized signups. Social login bypasses that verification step unless we add a post-login Yardi lookup, which negates the simplicity benefit. Salesforce Identity with self-registration and email verification gives us control over the registration flow. If the board requires social login later, it can be added as an optional secondary authentication method alongside Salesforce credentials.

Q7: How do you handle FixRight technicians who resist switching from their existing SSO to Google Workspace at month 12?

The identity transition is part of the broader FixRight integration. At month 12, technicians are provisioned in Google Workspace first, which places them in the HNPG-Field-Technician-{Region} group. On first SSO login to the HNPG org, a SAML JIT handler (Apex class extending Auth.SamlJitHandler) runs as a dedicated integration user, creates the HNPG user with FederationIdentifier set to the Google Federation ID, ProfileId = FieldServiceTechnician, the Field Service Mobile user license, and the PSG_Field_Service_Technician Permission Set Group mapped from the Google group claim in the SAML assertion. Unmatched group claims fall back to a read-only HNPG_Unassigned profile that alerts IT for manual review. The change management plan includes: a 2-week notice period with training sessions on Google Workspace, a dedicated IT support window during the first week of cutover, and company-provided tablets pre-configured with Google SSO. Technicians on BYOD personal phones get step-by-step setup instructions. Since FixRight is a wholly-owned subsidiary, this is an employment requirement, not an option — but the goal is to make it frictionless.

Q8: MFA is optional for tenants — what if the board requires mandatory MFA? How does that change your architecture?

Mandatory MFA for 45,000 tenants would increase login friction and likely reduce portal adoption below the PHP portal baseline. If required, Salesforce Identity Verification already supports SMS OTP out of the box via Salesforce’s own SMS delivery — enabling it is a configuration change at the profile and session policy level. However, routing the SMS through Twilio with HNPG branding is not a config toggle: it requires implementing a custom OTP provider (Auth.CustomOneTimePasswordDeliveryHandler interface), setting up an authenticated callout to Twilio via Named Credentials, and writing an Apex handler for the OTP send and verification lifecycle. Both options carry higher operational cost — Salesforce SMS is included but less flexible, Twilio is branded but requires Apex code and a maintenance burden. The bigger concern either way is tenants who change phone numbers and get locked out, which increases support call volume. I would propose a phased approach: mandatory MFA (Salesforce default SMS) for tenants who enable autopay, optional for maintenance-request-only users, with a review at 6 months before investing in a custom Twilio OTP provider.

Multi-Org and Migration

Q9: During the 12-month coexistence, what if MuleSoft goes down and work orders stop syncing?

Anypoint MQ queues messages with automatic retry and dead-letter handling. If MuleSoft is unreachable, Platform Events replay from the last checkpoint using the Pub/Sub API’s 72-hour event message durability window (current Salesforce retention for Platform Events and CDC events). Work orders queue in MuleSoft and sync when connectivity restores. Technicians are not blocked — they work in whichever org they are assigned to. A monitoring dashboard alerts the integration team if sync falls behind by more than 15 minutes. For extended outages beyond 2 hours, a pre-provisioned HNPG-FixRight-Bridge-Ops Google Workspace group is activated for a named set of FixRight dispatchers, and the standard SAML JIT handler provisions them in the HNPG org with read-only access to the Work Order dispatch queue and property access instructions. The provisioning path is identical to the normal technician JIT flow — pre-configured and rehearsed in the Full Copy sandbox during Phase 1 so activation is a single group change, not a runtime design decision. Emergency maintenance with a 30-minute SLA bypasses the sync entirely: the HNPG dispatcher calls FixRight dispatch directly by phone and enters the work order manually into both orgs until the bridge recovers.

Q10: Why not merge FixRight into the main org immediately and give external clients portal access?

Three reasons. FixRight’s external clients have contractual SLAs tied to FixRight’s existing processes and org. Rebuilding those workflows in the HNPG org is scope and budget risk. 150 technicians learning a new system while serving two client bases increases error rates during the transition. The 12-month coexistence lets us migrate FixRight users to the HNPG org on a clean break when contracts expire, with no service disruption. The MuleSoft bridge cost is modest compared to the risk of a failed big-bang migration.

Q11: How do you handle FixRight’s 22 custom objects and 8 Apex triggers during migration?

Audit FixRight’s custom objects against the HNPG data model. Expect 40-50% to map directly to standard Field Service objects or HNPG custom objects. The remaining are FixRight-specific extensions (property access instructions, vendor parts tracking). Migrate those that have active data as custom objects in the HNPG org. Apex triggers are reviewed - if they replicate HNPG Flow logic, deprecate them. If they provide unique FixRight functionality, convert to Flows where possible. The deduplication challenge is real: FixRight served some HNPG properties as an external contractor, so duplicate property and contact records exist across both orgs. External IDs (Yardi Property IDs) serve as the deduplication key. Migration happens at month 12-14 with a dedicated sprint.

Data and LDV

Q12: 45,000 sensor events per day — at what point do you hit Salesforce storage limits, and what is your archival strategy?

Salesforce sizes storage in GB, not record counts. The base data storage allocation for Enterprise Edition is 10 GB plus 20 MB per user license. For this org (roughly 1,200 internal, tenant, and owner users factored into storage), the baseline allocation is approximately 34 GB, with additional storage purchasable in blocks. Standard custom object records are 2 KB each for the purposes of storage calculation. At 45,000 sensor events per day with a 90-day retention, the naive storage is 4.05 million records × 2 KB ≈ 8.1 GB — which would consume a quarter of baseline allocation for one object alone. At the 2,000-property target with 765,000 events/day and 90-day retention, that becomes 68.85 million records × 2 KB ≈ 138 GB, which is untenable.

The architecture avoids this entirely by not storing raw telemetry in Salesforce. MuleSoft streams all Particle 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 no active work order) as Sensor Event records in Salesforce. At a realistic 2% alert ratio, Sensor Event stabilizes under 1,000 records per day even at 2,000-property scale — approximately 90,000 records × 2 KB ≈ 180 MB for a 90-day window, negligible against storage allocation. This architecture is identical at 120 properties and 2,000 properties, which satisfies Req 29 (scale without architectural rework). Historical telemetry queries for trend analysis run against the data lake via Tableau Server or direct SQL; they do not touch Salesforce storage.

Q13: With 45K tenants and 12K properties, what are the largest objects by volume, and have you planned for data skew?

Raw Particle telemetry (45,000 events/day today, ~765,000/day at 2,000-property scale) is deliberately not stored in Salesforce — MuleSoft routes it directly to the external data lake. Only actionable alerts land in Salesforce as Sensor Event records, keeping that object under 1,000 records/day even at full scale. That leaves Payment as the largest operational object at 8,000 events/day from Stripe (~8 GB over 3 years at 2 KB/record), followed by Work Order at ~14,400/year and Lease at 45,000 active. For data skew, the primary risk is on the Property lookup: large commercial properties with hundreds of units could concentrate thousands of Lease and Maintenance Request records under a single parent. Since Unit and Lease use Lookup relationships with Private OWD (not M-D with Controlled by Parent), sharing recalculation is lighter, but bulk DML on child records can still cause lock contention during sharing rule evaluation. Mitigation: bulk DML operations on child records are batched by Property to avoid parent lock conflicts. Yardi sync uses MuleSoft to distribute updates across properties rather than processing all 15K daily events in a single batch.

Q14: Yardi is the system of record, but what if a tenant updates their phone number in the Salesforce portal? Does that flow back to Yardi?

Clear domain ownership prevents conflicts. Yardi owns lease, financial, and tenant profile data (name, email, mailing address). Salesforce owns operational data (maintenance requests, work orders, portal preferences). Tenant profile updates in the portal (phone number, notification preferences) are stored in Salesforce on Contact fields that are not part of the Yardi sync. If the tenant needs to update their legal name or mailing address for lease purposes, the portal directs them to contact their property manager, who updates the record in Yardi. The Yardi-to-Salesforce sync then propagates the change. This avoids bidirectional conflict on tenant profile fields.

Q15: How do you handle the 3-year historical work order data from ServiceTitan? Is it searchable in the new system?

The 85,000 historical work orders from ServiceTitan’s SQL Server backup are loaded as read-only records in Salesforce with a “Historical - ServiceTitan” record type. They are searchable via standard Salesforce search and reportable for trend analysis (year-over-year maintenance costs, recurring issues by property). These records are not editable because they represent completed work from a decommissioned system. The data migration maps ServiceTitan fields to HNPG Work Order fields where possible. Fields that do not map cleanly are stored in a long text “Legacy Notes” field. Property correlation uses address matching validated against Yardi property records.

Q16: Why a four-level property hierarchy (Owner > Property > Building > Unit) instead of three levels?

Owner is a standard Account with Record Type “Owner Portfolio” (IsCustomerPortal=true), not a custom object — this is the only supported Experience Cloud user provisioning path because Customer Community Plus users must be created from Contacts on an Account. Property is a custom object with an Owner_Account__c lookup that connects it to the Owner Account. The Building level exists because many HNPG properties are multi-building complexes (apartment communities with 5-10 buildings, commercial campuses). Without Building, a 200-unit apartment complex would have 200 Units directly under Property, making it difficult to assign maintenance by building, track building-level occupancy, or schedule building-specific preventive maintenance (elevator service applies to a building, not a unit or property). For single-family rentals, the Building record is 1:1 with Property — a minor data overhead that keeps the model consistent. The M-D chain only goes two levels deep (Property > Building) to stay within the 3-level platform limit. Unit uses a Lookup to Building with Private OWD so that Sharing Sets on Unit (via Primary_Tenant_Contact__c) isolate tenants to their own unit. If Unit were M-D to Building, a Sharing Set on Property would expose all units under that property to every tenant, violating per-unit data isolation. Lease is also a Lookup to Unit with Private OWD, because adding it as M-D would create a 4-level chain (Property > Building > Unit > Lease) exceeding the platform limit.

Field Service

Q17: How does offline work for a technician in a parking garage basement with zero connectivity?

The Field Service mobile app with offline priming through a combination of Field Service Mobile Settings and Briefcase Builder. Field Service Mobile Settings controls per-assignment data that changes frequently — the technician’s assigned Work Orders, Service Appointments, and related Maintenance Request, Contact, and Property access information. Briefcase Builder (with High Volume Priming) handles reference data that changes less frequently and benefits from complex record selection rules — property playbooks, preventive maintenance procedures by property type, parts catalog, and certification lookups. Briefcase Builder does support Field Service mobile offline priming in current releases, which is why the architecture uses both rather than treating them as mutually exclusive. In the basement, the technician views work order details, logs time, captures photos, records parts used, and collects tenant signature — all stored locally. When the technician exits the basement and regains signal, the app automatically syncs within 60 seconds. Conflict resolution: last-write-wins with server timestamp, though conflicts are rare because work orders are assigned to a single technician.

Q18: Preventive maintenance for 12,000 properties - how do you avoid overwhelming technicians with recurring work orders?

Preventive maintenance schedules use Maintenance Plans (standard Field Service object) with configurable frequency per property type. HVAC inspections quarterly for commercial, biannually for residential. Maintenance Plans generate Work Orders automatically based on the schedule, but assignment uses the scheduling optimizer to distribute across available technicians by skill, location, and capacity. Regional managers can pause preventive schedules during peak seasons (e.g., summer HVAC demand for emergency repairs in AZ/NV/TX). The SLA enforcement ensures emergency requests always take priority over preventive work orders in the dispatch queue.

Portals and Integration

Q19: 45,000 tenant logins on Experience Cloud — have you load-tested this assumption?

45,000 users is modest by Experience Cloud standards — Customer Community Plus supports multi-million-user deployments and the platform is architected for B2C-scale portals. The real pressure is not total user count but concurrent session spikes on rent due dates (first of the month) and wave migration cutovers. The architecture includes a dedicated load testing phase: Full Copy sandbox with synthetic 45K tenant dataset, k6 simulating 5,000 concurrent sessions (peak estimate based on 10-12% concurrent rate at rent due date). Tenant portal is read-heavy — lease details and payment history are cached. Maintenance request submission is the primary write operation at 1,200/month (40/day), which is low. If load testing reveals bottlenecks, mitigation includes CDN caching, LWC lazy loading for maintenance history, and MuleSoft experience API caching for Yardi-sourced data. The wave-based tenant migration (5K, 20K, 20K) provides natural load ramp-up with real traffic before full scale.

Q20: Yardi is the system of record but Salesforce creates work orders. How do you avoid conflicting data?

Clear domain ownership. Yardi owns lease, financial, and tenant profile data. Salesforce owns work orders, maintenance requests, and technician operations. MuleSoft enforces this: Yardi-to-Salesforce sync is authoritative for lease fields (if Yardi and Salesforce disagree, Yardi wins). Salesforce-to-Yardi sync pushes work order costs for owner financial reporting but never overwrites lease or financial data. External IDs (YardiLeaseId, YardiPropertyId) on Salesforce records provide the correlation key. Conflict alerts notify the integration team if a sync detects a mismatch on a field that both systems should agree on.

Q21: The IoT platform covers only 120 properties. Is it worth building now?

Yes, but scoped appropriately. The IoT integration is lightweight: Particle webhooks to MuleSoft, MuleSoft evaluates thresholds, and alerts create Maintenance Requests via standard Salesforce APIs. The build cost is low (Phase 3, $0.6M shared with analytics). The architecture is scalable - adding a property means registering its sensors in Particle and creating Sensor Device records in Salesforce. No code changes. Waiting until 2,000+ properties have sensors would mean retrofitting IoT into an architecture that was not designed for it. The 90-day archival and external data lake strategy for historical telemetry are designed for the 2,000+ property target, not just the 120-property starting point.

Governance and Delivery

Q22: $3.8M for 18 months with only 10% contingency seems tight. Where do you cut if costs overrun?

The budget is split between SaaS license operating expense (~~$2.2M over 18 months) and implementation services plus infrastructure (~~$1.2M) plus the $0.4M contingency. The largest license variable is Customer Community Plus Login for 45,000 tenants, where a shift from under-30% monthly active login rate to over-30% would force a pricing model change. The next largest are Sales/Service/Field Service internal licenses at ~$1.2M over 18 months and Shield at ~$270K (Platform Encryption plus Event Monitoring plus Field Audit Trail, priced as a percentage of base license fees).

Phase 3 (Smart Building + Analytics) is the buffer. IoT integration for 120 properties and CRM Analytics dashboards are valuable but not operationally critical. CRM Analytics is a separately licensed add-on (CRM Analytics Growth at $125/user/month, gated on the Use CRM Analytics permission) and security is modeled with CRM Analytics Security Predicates keyed on Region__c and Owner_Account__c to respect the five-population sharing model — not free and not an afterthought. If Phase 1 or 2 overruns, Phase 3 scope reduces to IoT emergency alerts only (water leak auto-dispatch) and basic standard Salesforce reports instead of CRM Analytics dashboards, freeing up the 20 CRM Analytics seats ($45K over 18 months). The core platform, Field Service, and portals are non-negotiable — they solve the primary business problems.

Q23: How do you ensure the PHP portal decommission does not leave tenants stranded?

Three safeguards. First, wave-based migration (5K, 20K, 20K) with a pilot group that validates the experience before full rollout. Second, 30-day parallel run where both PHP portal and new tenant portal are active. Third, exit criteria for decommission: zero critical bugs, 95%+ tenant login success rate, and maintenance request submission rate matches or exceeds PHP baseline. If exit criteria are not met, the PHP portal stays active and the parallel run extends. The single PHP developer is retained through the parallel run period for emergency fixes.

Q24: You chose MuleSoft for 8 integrations. Is that overkill compared to Salesforce-native integration?

Eight integrations, but the critical factor is Yardi bidirectional sync. Yardi is the financial system of record - if that sync fails silently, owner reports show wrong data and trust collapses. MuleSoft provides centralized monitoring, retry logic, and alerting that Salesforce-native tools (External Services, named credentials + Apex) cannot match at this reliability level. Add the FixRight bridge, IoT event processing, and Stripe webhooks, and the middleware layer justifies itself. If budget were tighter, I would consider Salesforce-native for DocuSign and Twilio (low-complexity, outbound-only) while keeping MuleSoft for Yardi, FixRight, IoT, and Stripe.

Q25: How do you handle CCPA data access and deletion requests for the 8,000 California tenants?

CCPA requests span multiple systems: Salesforce (portal activity, maintenance requests, work orders), Yardi (lease data, tenant profile), Stripe (payment history), and TransUnion (screening records). The architecture handles this through a CCPA request queue in Salesforce — a custom object that tracks each request with a 45-day SLA clock. For data access requests, MuleSoft orchestrates data retrieval from Salesforce, Yardi, and Stripe into a consolidated report.

Deletion is not uniform across systems because CCPA 1798.105(d) exempts records needed for completing a transaction, complying with legal obligations, or detecting security incidents. Lease ledger and payment history in Yardi are retained for 7 years under tax and accounting obligations (IRS 1099 generation, landlord retention laws). Stripe retains payment metadata indefinitely for fraud, chargebacks, and tax purposes — Stripe’s deletion workflow is manual and takes weeks, and transaction hashes and fraud signals are never fully removed. TransUnion screening records are retained under Fair Credit Reporting Act obligations.

The actual deletion workflow is: (1) purge tenant PII fields from Salesforce Contact (name, email, phone anonymized; portal user deactivated); (2) forward an anonymization directive to Yardi and Stripe so they redact portal-facing PII while retaining the transaction ledger; (3) document the retention exemption for Yardi ledger, Stripe payment metadata, and TransUnion screening as required response content — CCPA allows retention-with-exemption as a valid deletion response when the business identifies the exemption reason in the 45-day window. During the 12-month FixRight coexistence, the deletion scope in FixRight is limited to work order metadata and access logs referencing the pseudonymous tenant token (no raw PII ever crosses the bridge, so there is no PII to delete in FixRight). The audit trail for the CCPA request itself — who submitted it, when the response was sent, which systems retained what under which exemption — is preserved on the request object for compliance documentation and exported to the S3 archive alongside Event Monitoring data.

Question Categorization

Domain	Questions
D1 System Architecture	Covered in presentation deep dives
D2 Security	Q1, Q2, Q3, Q4, Q5
D2 Identity/SSO	Q6, Q7, Q8
D3 Data / LDV	Q12, Q13, Q14, Q15, Q16
D4 Solution Architecture	Q21, Q24
D5 Integration	Q9, Q20, Q21
D6 Dev Lifecycle	Q10, Q11, Q22, Q23
D6 Compliance	Q25
D7 Communication	Q17, Q18, Q19

Q&A Survival Rules

Answer the question asked. Do not pivot to a topic you prepared better for.
State position first, then reasoning: “I chose X because Y. I rejected Z because W.”
Name the trade-off proactively. Judges respect honesty over pretending there is no cost.
Say “I don’t know” when appropriate: “I would validate that during the design phase”
Stay within 1-2 minutes per answer

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.

Personal study notes for the Salesforce CTA exam. Content compiled from VJ's study notes, official Salesforce documentation, community sources, and online publicly available content, then organized and presented with AI assistance. Not affiliated with Salesforce. © 2025–2026 VJ Srivastava.