Skip to content

Q&A Prep 01: Apex Wealth Partners

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.

Q&A Context

Format: 10-minute Q&A following a 15-minute presentation Judges will ask 4-6 questions in 10 minutes. Practice answering each in 60-90 seconds.

Q&A Strategy

Listen fully before answering. Restate briefly. Structure as: decision, reasoning, trade-off acknowledged. If unsure, say “I would need to investigate further, but my initial thinking is…” — judges respect honesty over bluffing.

Q1: Why a single org instead of two orgs connected by Salesforce Connect? (D1)

The core requirement is a unified client view for 180,000 accounts with 8,000 overlapping clients. External objects via Salesforce Connect do not support aggregate SOQL or roll-up summary fields, making household-level AUM aggregation architecturally impossible at scale. The trade-off is that a single org makes the Chinese wall harder, addressed with Restriction Rules below the sharing model.

Q2: How do you handle the existing org’s technical debt? (D1)

Phase 0 includes org assessment: field utilization analysis to flag fields under 5% population for archival, mapping 85 custom objects against FSC equivalents with migration paths, and refactoring 47 triggers into a trigger framework with proper tests. This cleanup happens before any new feature work to avoid compounding technical debt.

Q3: How does the architecture handle growth to 250K accounts and future acquisitions? (D1)

Three decisions support scalability. FSC’s data model is acquisition-ready — new client bases map into the same Person Account/Financial Account/Household structure. MuleSoft’s API-led connectivity means adding a new custodian is a new connector, not a rearchitecture. Territory-based sharing rules scale horizontally — new regions are territory assignments, not structural changes.

Q4: Walk through exactly how the Chinese wall works technically. (D2)

Has_MNPI__c checkbox on Person Account is set when MNPI exists for a client. A Restriction Rule hides that record from all users except those with the MNPI_Authorized_Viewer Permission Set (compliance officers and commercial lending only). Restriction Rules execute after sharing, narrowing access — distinct from sharing rules which grant access. An advisor with a legitimate personal account relationship cannot see the MNPI-flagged commercial data.

Q5: How do you prevent a Salesforce admin from bypassing the sharing model? (D2)

Three SOX controls: View All Data/Modify All Data stripped from admin profiles and granted only via a break-glass Permission Set requiring CTO + CCO dual approval. Setup Audit Trail logs every metadata change with weekly compliance digests. Shield Event Monitoring tracks all admin record access. Quarterly access certification reviews all admin-level permissions.

Q6: Why not use Shield Encryption for the Chinese wall instead of Restriction Rules? (D2)

Shield encrypts data at rest but does not control record visibility — encrypted fields are still visible to users with field-level access. The Chinese wall is a visibility problem requiring records hidden from queries, list views, reports, and search. We use both: Encryption for data-at-rest protection, Restriction Rules for record-level visibility control.

Q7: How do you resolve the 8,000 duplicate records? (D3)

Three steps. Matching: MuleSoft runs banking records against wealth org using Duplicate Rules with fuzzy matching on name, SSN, DOB, and address. Survivorship: wealth wins investment fields, banking wins deposit fields, most recent wins demographics. Validation: data steward reviews high-value merges (AUM > $1M or deposits > $500K) before commit; lower-value matches auto-merge with exception reporting.

Q8: The nightly custodian load is 800K records. What if it fails mid-batch? (D3)

Idempotent chunk-based processing: 10K-record chunks write to a staging object first. After all chunks staged, reconciliation compares count against source file. If matched, upsert from staging to Financial Holding via external ID. Failed chunks retry 3x, then go to a dead letter queue with alerts. Remaining chunks continue. Partial failure does not corrupt already-loaded data.

Q9: How do you handle FIS Horizon having no real-time events? (D3/D5)

Hybrid approach. For operational use (branch staff opening a client view), synchronous SOAP callout through MuleSoft to FIS for current balance — request-reply, not cached. Transaction data is not stored in Salesforce (400K txn/day exceeds storage economics, stale-data risk). For analytics, nightly FIS batch loads summary-level data (balances, transaction counts, fee totals).

Q10: Why MuleSoft instead of Salesforce-native integration? (D4)

Six systems with three protocols (SFTP, SOAP, REST), 2M-record nightly volume within a 5-hour window. Native callout limits (100 per transaction, 120-second timeout) and Platform Event daily limits would be stressed. MuleSoft provides protocol mediation, centralized error handling with dead letter queues, and a monitoring dashboard for operations. For a SOX-regulated firm, centralized middleware with integration audit trails is a defensible investment.

Q11: What is your error handling for the Orion bidirectional sync? (D5)

Outbound (demographics to Orion): Platform Event fires on Person Account changes, MuleSoft subscribes and calls Orion Connect with exponential backoff retries (30s/60s/120s). Failed events go to dead letter queue. Inbound (performance data): nightly batch with staging-and-reconciliation pattern. Conflict resolution: Salesforce wins demographics, Orion wins performance/billing.

Q12: How do you ensure Smarsh captures all communications without gaps? (D5)

Three parallel mechanisms: Exchange journal rules capture all email before it reaches the user. Platform Events on Task/Event creation push to Smarsh via MuleSoft. Portal secure messages logged as Salesforce records and pushed via the same pipeline. Smarsh returns an archive ID stored on the Activity record for back-linking. Daily reconciliation compares Salesforce activity counts against Smarsh archive counts by advisor.

Q13: The firm has never had release management. How do you bootstrap it? (D6)

Phase 0 establishes Salesforce DX project structure, GitHub repository, branch strategy, and GitHub Actions CI/CD pipeline with four gates: Apex tests (85% minimum), static analysis (PMD/ESLint), CCO approval for security-tagged changes, and deployment validation. Consulting partner models the process in Phase 1, internal team runs it independently by Phase 2, full CoE self-sufficiency by Phase 4. No one touches production directly.

Q14: A judge says your Chinese wall relies on a checkbox a human must set. What if they forget? (D2/D7)

Three safeguards: automated flow on the banking side evaluates commercial lending engagement records and auto-sets Has_MNPI__c when triggered (IPO advisory, M&A engagement, debt syndication). Weekly compliance dashboard reviews new flags and audits unflagged clients with active commercial engagements. Failsafe: Event Monitoring alerts when any wealth advisor searches for a banking commercial client they do not own, regardless of MNPI flag.

Q15: What is the single biggest risk to this program? (D7)

Data migration quality for the 8,000 overlapping clients. Incorrect survivorship means wrong AUM figures, wrong account statuses, and inaccurate compliance reports — a regulatory finding in financial services. Mitigation: 3-day data steward review for high-value merges, parallel validation period with both systems running, automated data quality dashboards flagging mismatched totals and missing fields, and a hard rule: postpone go-live rather than ship bad data.

Answer Framework for Unexpected Questions

  1. Restate: “If I understand correctly, you are asking about…”
  2. Decision: “My recommendation is…”
  3. Reasoning: “I chose this because…”
  4. Trade-off: “The trade-off I accept is…”
  5. Mitigation: “I mitigate that risk by…”

Time Control

If a judge asks a compound question, answer the more architectural question first and briefly acknowledge the second. Do not try to answer both in equal depth.