Case Study 1: Apex Wealth Partners - Presentation Notes

Work in Progress

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

Presentation Guide

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

Presentation Snapshot

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

Presentation Focus

Go deep on the single-org vs multi-org decision and the Chinese wall security model, as these are the defining challenges of the scenario.

Opening (3 min)

“Apex Wealth Partners faces a defining architectural crossroad: how to unify wealth and banking into a single client view while maintaining strict regulatory Chinese walls. My solution prioritises a single-org Financial Services Cloud Core approach, isolates MNPI data on a dedicated child record type with its own Private OWD, and uses a MuleSoft-led integration layer to handle the 2 million-record nightly custodian feeds. This 24-month program migrates banking before the Dynamics 365 renewal deadline while building a self-sufficient Center of Excellence.”

Show System Landscape. Frame the scale: 2,200 internal users, 180,000 client accounts, 8,000 overlapping clients, 6 external systems. State the single-org choice.

Deep Dive 1: Single-Org Strategy (8 min)

“The core business requirement is a unified 360-degree client view. With 8,000 overlapping clients, any multi-org strategy would require complex bidirectional sync or external objects that break real-time household rollups.”

Three-part justification:

1. Business value: Advisors and branch staff need one source of truth for household AUM and deposit totals to drive cross-sell. Native rollups in FSC require data co-location.
2. Compliance efficiency: SEC and FINRA audit requests require a single query surface. Two orgs would double the audit complexity and Shield cost.
3. Operational sustainability: The 10-person CoE cannot effectively manage two deployment pipelines, two sandbox sets, and two release calendars.

Trade-off: A single org makes the “Chinese wall” (information barrier) harder to enforce. I mitigate this by isolating MNPI-sensitive data on a child Financial Account record type with its own Private OWD and Apex Managed Sharing, which I will detail next.

Deep Dive 2: Security & The Chinese Wall (8 min)

“The wealth and banking divisions must operate independently, yet share a single record for overlapping clients. This is the hardest requirement in the scenario.”

Layered approach:

• Private OWD on Person Account. Foundation layer. Advisors see only their book.
• Split OWD on Financial Account by record type. Wealth and Banking record types use Private OWD with criteria-based sharing rules scoped by record type, so a wealth advisor who owns the Person Account still does not inherit Banking Financial Accounts. The Commercial Lending record type (which holds MNPI-sensitive data) is Private with Apex Managed Sharing to the commercial lending team only — the inheritance chain from Account is deliberately broken.
• Field-Level Security on Has_MNPI__c. The MNPI flag itself is hidden from wealth advisor profiles via FLS so advisors cannot even see that the flag exists on the Account record.
• Role Hierarchy: Two separate branches for Wealth and Banking. No cross-branch inheritance. Compliance sits as a peer with explicit Permission Set Group grants on a Minimum Access base profile (additive permission model).
• Restriction Rules on MNPI_Exposure__c junction (custom object). Defence-in-depth audit layer. Restriction Rules are supported on custom objects, external objects, contracts, events, quotes, tasks, time sheets, and time sheet entries — not on Account — so the custom junction is the correct Restriction Rule target.

Why not Restriction Rules on Account? Account is not a supported object for Restriction Rules in the current platform release. Restriction Rules also do not apply to record owners or users with View All / Modify All permissions, so the “wealth advisor owns the Person Account and the client later gets MNPI” edge case cannot be solved at the Account layer. Isolating MNPI data to a child object with its own Private OWD is the only pattern that works regardless of Account ownership.

Why Apex Managed Sharing on the Commercial Lending child record? Starting from a Private OWD with no inheritance and building shares up via Apex is additive, but from a zero baseline — the opposite of “remove access the hierarchy gave.” The Apex trigger grants Read/Write only to the commercial lending team and reconciles nightly, so the commercial lending team gets access and nobody else does.

Deep Dive 3: Nightly Custodian Ingest (7 min)

“We process 2 million records nightly from Schwab, Pershing, and Orion. Reliability and reconciliation are non-negotiable.”

MuleSoft API-led connectivity:

• Batch Pattern: MuleSoft retrieves SFTP files, performs Pershing-to-FSC transformation, and loads to Salesforce via the Bulk API.
• Reconciliation: We use a custom staging object to validate totals before promoting data to the production Financial_Holding records.
• Idempotency: Every record uses the custodian’s unique ID as an External ID in Salesforce.
• Error Handling: Chunk-level retries in MuleSoft ensure that a failure in one 10,000-record block does not stop the entire 800,000-record load.

Supporting Artifacts (9 min)

Data Model (2 min): FSC Core standard objects (Person Account, FinancialAccount, FinancialAccountParty for party-role relationships, Financial Holding). Greenfield build uses FSC Core, not the legacy managed package (FinServ__FinancialAccountRole__c) — any managed-package data is migrated to Core in Phase 0. Relationship Group for householding. LDV strategy: archive holdings older than 2 years and activities older than 18 months to Big Objects plus S3 to maintain query performance at 1.2M+ holdings and 12M+ activities.

Identity (1.5 min): Okta SAML 2.0 with a Custom Apex JIT Handler that parses Okta group membership and assigns Permission Set Groups on login (standard SAML JIT only sets User record fields, not PSGs). Experience Cloud native identity plus MFA for clients. Separation ensures clients never touch internal identity infrastructure. MuleSoft integration auth uses an External Client App (the Spring ‘26 successor to Connected Apps) with OAuth 2.0 Client Credentials.

Data Migration (1.5 min): Dynamics to FSC migration in Phase 2 via Bulk API 2.0. Duplicate detection (8K overlaps) using fuzzy matching on Tax ID and Name. Survivorship: Wealth wins for suitability, Banking wins for loan data, most-recent wins for demographics. Phase 2 also migrates 1.2 TB of SharePoint banking documents to AWS S3 with object-lock (WORM) via MuleSoft bulk transfer and exposes them through Files Connect — the paper requires migration, not just surfacing.

Governance (2 min): 10-person CoE. Monthly release cadence. CCO approval gate in Staging for all security/compliance changes. SOX-compliant pipeline using GitHub Actions and automated 85% coverage enforcement.

Roadmap (2 min): 24 months. Phase 0: Foundation and FSC Core migration. Phase 1: Wealth (low risk). Phase 2: Banking plus SharePoint document migration (high risk, Dynamics renewal deadline). Phase 3: Portal. Phase 4: Optimisation. Phase 2 must complete before month 14 to avoid the Dynamics renewal; SharePoint migration runs in parallel with banking console build inside Phase 2.

Transitions

• Opening to Single-Org: “Let me start with the defining strategic decision: why a single org for two regulated divisions?”
• Single-Org to Security: “Since we are in a single org, the question becomes: how do we prevent a wealth advisor from seeing sensitive banking data?”
• Security to Integration: “With the data boundaries secure, let’s look at how we bring 2 million records into that environment every night.”
• Integration to Supporting: “With the three highest-risk decisions covered, let me walk through the remaining artifacts.”

Closing & Risks (7 min)

Three risks and mitigation:

1. Dynamics 365 renewal (Month 14): Phase 2 prioritised to start in month 6; 2-month buffer on the deadline.
2. Chinese wall breach: Automated regression tests in the CI/CD pipeline verify OWD, criteria-based sharing rules on Financial Account record types, Apex Managed Sharing on the Commercial Lending record type, and FLS on the MNPI flag on every deployment.
3. Custodian load performance: Staging object pattern + Bulk API v2.0; full-copy load testing in Phase 0.

“Apex Wealth Partners gains a unified client view and a modernised platform while maintaining strict regulatory compliance. The architecture is simple enough for a 10-person CoE to maintain, yet strong enough to handle 2 million nightly updates.”

Timing Checkpoints

Segment	Duration	Cumulative
Opening	3 min	3 min
Single-Org Deep Dive	8 min	11 min
Security Deep Dive	8 min	19 min
Integration Deep Dive	7 min	26 min
Supporting Artifacts	9 min	35 min
Closing	3 min	38 min
Risk & Trade-offs	4 min	42 min
Buffer	3 min	45 min

Related Topics

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

---

Always verify against official Salesforce documentation

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