Case Study 1: Apex Wealth Partners - 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.

System Architecture (D1)

Q1: Why not a multi-org strategy given the strict Chinese wall requirement?

The business requirement for a unified client view and household-level AUM rollups across 8,000 overlapping clients is the primary driver. In a multi-org model, you lose native rollups and real-time visibility. I chose a single org because the business requirement is a unified client view across 8,000 overlapping clients, and MNPI data is isolated on a dedicated child Financial Account record type with its own Private OWD and Apex Managed Sharing — not by Restriction Rules on Account, which are not supported.

Q2: How does the “unified client view” work for a client who hasn’t consented to cross-sell?

The client record (Person Account) is shared, but the division-specific child records (Financial Accounts) remain isolated by the sharing model. A wealth advisor sees that a banking relationship exists (via the Account record) but cannot see the loan or deposit details unless the Consent_Given__c flag is checked, which triggers a sharing rule. This provides a “unified presence” without violating privacy.

Q3: You recommended FSC. Justify the additional license cost over standard Sales Cloud.

FSC provides the Financial Account, Financial Holding, and Relationship Group (Householding) objects out of the box, along with the roll-up engine. Building this on Sales Cloud would require ~15-20 custom objects, complex Apex rollup triggers, and significantly more maintenance for the 10-person CoE. The license cost is offset by reduced development time and native support for household-level wealth management.

Security (D2)

Q4: Account is not a supported object for Restriction Rules. How do you enforce the Chinese wall?

Correct — Restriction Rules are supported on custom objects, external objects, contracts, events, quotes, tasks, time sheets, and time sheet entries, but not on Account, Contact, Opportunity, Case, or Lead. I do not put the Chinese wall on Account. MNPI-sensitive data lives on a dedicated child Financial Account record with RecordType = 'Commercial Lending'. That child record has its own Private OWD — deliberately not Controlled by Parent — so ownership of the Person Account does not cascade down. An Apex Managed Sharing trigger grants Read/Write on the Commercial Lending record only to the commercial lending team and the MNPI_Authorized_Viewer group; nobody else, including the Person Account owner, gets a share row. Field-Level Security hides the Has_MNPI__c flag on Person Account from wealth advisor profiles so they cannot even see the flag exists. For defence-in-depth I add a custom MNPI_Exposure__c junction object (which is a supported Restriction Rule target) that tracks which authorised users have seen which disclosure — that Restriction Rule filters junction rows to authorised viewers only.

Q5: A wealth advisor owns a Person Account. That client later has commercial lending MNPI added. Walk me through what the advisor can and cannot see.

Because I isolated MNPI data on a child Financial Account with its own Private OWD, the advisor still sees the Person Account (they own it), still sees the wealth Financial Accounts (criteria-based sharing rule on RecordType = 'Wealth' to the Wealth Advisors group), and still sees banking-consented deposit data if the Consent_Given__c flag is checked. What they do not see is the Commercial Lending Financial Account record, the commercial lending holdings beneath it, or the Has_MNPI__c field on Person Account (FLS hides the field from wealth advisor profiles). Restriction Rules do not apply to record owners or users with View All permissions, which is why I could not rely on a Restriction Rule on Account — the advisor would always see the record they own. Moving MNPI data to a child object with its own Private OWD breaks the ownership inheritance and is the only pattern that holds up under this edge case.

Q6: Why not use Shield Encryption for the Chinese wall?

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. Shield is still part of the solution: Platform Encryption protects restricted fields (SSN, account numbers, positions) at rest in the Salesforce database, while the sharing model (split OWD on Financial Account by record type plus Apex Managed Sharing on Commercial Lending plus FLS on the MNPI flag) is what actually enforces the Chinese wall on who can see which record.

Data (D3)

Q7: 1.2M Financial Holdings will grow quickly. What is your LDV strategy?

I use a two-tier strategy. “Hot” data (active holdings) remains in standard objects. “Cold” data (historical positions > 2 years old) is archived to Big Objects using a nightly batch job. This keeps the Financial_Holding table size manageable, ensuring that custodian reconciliation and advisor reports remain performant.

Q8: How do you handle 8,000 overlapping clients during the Dynamics migration?

We use a duplicate detection rule on Tax ID and Name during the Phase 2 load. When a match is found, we use a survivorship Apex class: the existing Wealth record’s suitability and risk data are preserved, while the Banking loan and deposit fields are merged into the record. Demographic data follows a “most recent wins” policy.

Integration (D5)

Q9: 800,000 nightly records from Schwab/Pershing. How do you ensure the org doesn’t hit limits?

We use the Bulk API 2.0 via MuleSoft, which handles the 100-million record daily limit easily. To prevent trigger recursion and locking issues, we load into a staging object first. An async Apex process then processes the staging records in chunks of 2,000, promoting them to the Financial Holding object during low-traffic hours (11 PM - 4 AM).

Q10: What happens if the FIS Horizon real-time inquiry fails?

I’ve implemented a circuit breaker pattern in MuleSoft. If FIS is down or timing out, Salesforce displays a “Banking data temporarily unavailable” message with a timestamp of the last successful refresh. This prevents a cascading failure where slow FIS responses tie up Salesforce threads and impact overall org performance.

Dev Lifecycle & Governance (D6)

Q11: How do you enforce the SOX “segregation of duties” in your deployment pipeline?

The GitHub Actions pipeline is configured so that the person who merges a Pull Request into main cannot be the same person who authored the code. Production deployments are restricted to the Release Manager (CoE Lead), and developers only have access to their respective sandboxes.

Q12: You have 10 people in your CoE. How do they support 2,200 employees across 2 divisions with 180,000 client accounts?

The 10-person CoE focuses on platform governance, shared metadata, and high-risk integrations — not on first-line support for every user. For the 2,200 internal employees (600 advisors, 400 branch staff, 200 ops, 150 compliance, 850 other), we designate “super users” in each division to handle low-risk changes like reports, dashboards, and email templates. The CoE acts as an Architectural Review Board for any change touching the sharing model, data schema, or integrations. The 180,000 client accounts are data volume, not user volume — those clients access the platform through the Experience Cloud portal and do not require CoE support for day-to-day use.

Closing & Trade-offs

Q13: What is the single biggest risk to this 24-month timeline?

The Dynamics 365 renewal at month 14. If the banking migration (Phase 2) slips, we incur significant unbudgeted licensing costs. My mitigation is to start the data cleansing and mapping workstream for banking in month 4, in parallel with the Wealth enhancements, giving us a 10-month window for a 6-month migration task.

Q14: What is the top trade-off you made in this architecture?

I accepted the complexity of a single-org sharing model (role hierarchy, criteria-based sharing rules on Financial Account by record type, Apex Managed Sharing on the Commercial Lending record type, and field-level security on the MNPI flag) to gain the unified client view. The alternative — two orgs — is simpler for security but fails the core business requirement of household-level aggregation. I believe the operational overhead of the multi-layer sharing model is a fair price for the business value delivered.

Q15: Why prioritize the Advisor Console (Phase 1) over the Client Portal (Phase 3)?

The portal depends on the unified data model. If we launched the portal in Phase 1, clients would only see their wealth data, requiring a second “launch” later for banking. By launching the Advisor Console first, we stabilize the internal data model and integration flows before exposing that data to external clients, reducing the risk of a poor client experience.

Identity & SSO (D2)

Q16: Walk me through the Okta-to-Salesforce SSO flow. How are Permission Set Groups assigned on login, and what happens if JIT provisioning fails?

The flow is SP-initiated SAML 2.0. The employee navigates to Salesforce, gets redirected to Okta, authenticates with password plus MFA push, and Okta returns a SAML assertion containing the Federation ID and attribute mappings (profile, user role, division, Okta group membership). Salesforce receives the assertion at the ACS URL, matches the Federation ID to a User record, and establishes a session.

Standard SAML JIT provisioning only sets fields on the User record (Profile, Role, Email, FirstName, etc.) — it cannot assign Permission Sets or Permission Set Groups natively. To map Okta groups to PSGs, the architecture uses a Custom Apex JIT Handler that implements the Auth.SamlJitHandler interface. On each login, the handler reads the Okta group attribute from the SAML assertion, looks up the matching PSG name in a JIT_Group_Mapping__mdt custom metadata table, and calls PermissionSetAssignment Apex to grant or revoke PSGs. The handler also writes an audit row to JIT_Event__c for CCO traceability.

If JIT provisioning fails (required SAML attribute missing, mapped Profile does not exist, Apex handler exception), Salesforce rejects the assertion and the user sees a login error. Mitigation: a nightly reconciliation job compares Okta group memberships against Salesforce User records and PSG assignments and flags mismatches before users encounter them. For the initial go-live, we pre-provision all 2,200 users via Data Loader rather than relying entirely on JIT, then switch to JIT-driven updates after stabilisation.

Q17: Banking staff are migrating from Azure AD to Okta. How do you handle the transition period?

During the 6-month Azure AD-to-Okta migration, we configure Salesforce to accept SAML assertions from both identity providers simultaneously using two SSO configurations (one for Okta, one for Azure AD). Each maps to the same Federation ID attribute. As banking staff migrate to Okta in batches, their Azure AD SSO config is deactivated. After all banking staff are on Okta, we decommission the Azure AD SSO config entirely. MFA enforcement is active on both identity providers during the transition.

Q18: Why Customer Community Plus licenses for the portal instead of standard Customer Community?

Customer Community Plus supports role-based sharing and sharing rule inheritance, which we need so that each client sees only their own household’s financial data. Standard Customer Community licenses do not participate in the sharing model the same way. The portfolio view requires the sharing model to scope Financial Account and Financial Holding records to the authenticated client’s household. With standard Customer Community, we would need to build custom Apex controllers to enforce record-level access, adding development cost and audit surface area.

Mobile & Performance (D1)

Q19: What is your mobile strategy for advisors? 30% of meetings are off-site.

Advisors use the Salesforce Mobile App with a custom navigation set showing Accounts, Financial Accounts, Activities, and key dashboards. Mobile Application Management through Microsoft Intune enforces device-level security: passcode lock, remote wipe capability, and jailbreak detection. The sharing model enforces the same MNPI isolation on mobile as on desktop — the Commercial Lending record type on Financial Account remains Private with Apex Managed Sharing, the criteria-based sharing rules scoped by record type still apply, and Field-Level Security hides the MNPI flag from wealth advisor profiles regardless of channel. Offline access is enabled for account records and activity logging so advisors can prepare for and document meetings without a network connection, with automatic sync on reconnect.

Q20: How do you handle the quarterly rebalancing peaks at 3x normal volume?

During rebalancing, Schwab trade confirmation webhooks spike to roughly 3x daily volume. MuleSoft handles this with horizontal worker scaling during declared peak windows. On the Salesforce side, Platform Events decouple webhook receipt from record processing, creating a buffer. The staging object pattern absorbs the increased nightly custodian load volume. We also schedule the quarterly rebalancing outside the nightly batch window so the two peak activities do not compete for the same processing hours.

LDV & Data Archival (D3)

Q21: Financial Holdings will grow past 1.2M quickly. When do you archive, and how do you handle point-in-time reporting?

Active holdings (current positions) stay in the standard Financial Holding object. Holdings older than 2 years move to a Big Object (Holding_Archive__b) via a nightly Batch Apex job. The 2-year threshold is based on the most common advisor reporting window. For point-in-time reporting (reconstructing what a portfolio looked like on a specific date), each Holding carries an As_Of_Date field. The Big Object’s composite index is defined as (AccountId, As_Of_Date, Holding_Id) in that exact order. Standard SOQL on Big Objects must filter fields in that composite-index order without gaps and can return at most 200 rows synchronously; query filters that skip AccountId or start with As_Of_Date only will not use the index and will fail or time out.

For a single-account lookback (advisor viewing their own client’s history), standard SOQL works cleanly because the query starts with AccountId. For cross-account point-in-time reconstruction across 500 accounts during a compliance exam, standard SOQL will not scale — Async SOQL on Big Objects was retired in Summer ‘23, so the correct pattern is a Bulk API 2.0 extraction or CRM Analytics external-data connection against the Big Object data set, feeding into a dataset that compliance queries through the Analytics UI. For the compliance-mandated 7-year lookback, the Big Object combined with Shield Field Audit Trail provides the reconstruction path for positions and field-level history without keeping 7 years of hot records.

Licensing (D1)

Q22: You have 2,200 employees plus portal users. Walk me through your license allocation and cost strategy.

600 advisors and wealth support staff get FSC licenses, which is an upgrade from the partially implemented FSC overlay they have today. 400 banking staff get FSC licenses with banking-specific page layouts and app assignments. 150 compliance staff get Service Cloud licenses — not Salesforce Platform, because Platform licenses do not grant access to the standard Case object and compliance needs View All on Case for the SOX access review and customer dispute history workflows. Service Cloud is the cheapest license tier that includes Case; the premium over Platform (roughly $75/user/month times 150 users, around $135K/year) is absorbed into the program budget. 200 operations staff also get Service Cloud licenses for case management. The client portal uses Customer Community Plus licenses for sharing model inheritance. Shield is a required add-on across the org for encryption, Field Audit Trail, and Event Monitoring — with an external S3 + Splunk archive feeding from Event Monitoring exports to cover the 7-year SEC/FINRA retention window that native Event Monitoring (max 1 year) does not reach. I would negotiate an enterprise agreement bundling FSC, Shield, Experience Cloud, and MuleSoft for a volume discount, since licensing is a significant portion of the $12M budget.

Error Handling & Integration Failover (D5)

Q23: What happens if the Schwab nightly SFTP feed fails entirely? Walk me through the advisor experience the next morning.

MuleSoft retries the file retrieval 3 times at 15-minute intervals. If the file is still unavailable, a PagerDuty alert fires to the on-call operations engineer. The staging object pattern means a failed load never corrupts existing data. Advisors see prior-day positions (stale but present) because the previous night’s successful load remains in the Financial_Holding records. The CIO dashboard shows a “data as of” timestamp so leadership knows the positions are 24 hours old. Operations escalates to Schwab support while the CoE prepares for a manual SFTP pull once the feed is restored.

Q24: Orion sync conflicts happen weekly today. How does your architecture fix that?

The current 4-hour sync produces conflicts because both systems can update the same demographic fields independently. My architecture defines clear data ownership: Salesforce is authoritative for demographics (name, address, contact info), and Orion is authoritative for performance and billing data. MuleSoft enforces these ownership rules during each 15-minute sync cycle. When an inbound Orion update attempts to overwrite a Salesforce-authoritative field, MuleSoft rejects the change and writes a record to a Conflict_Resolution__c staging object for manual review. This reduces conflicts from a weekly occurrence to an exception-only process.

Change Management & Vendor Risk (D6/D7)

Q25: Banking staff are unionized in 3 states. How does that affect your rollout?

Union contracts in those states require formal notification and consultation before system changes that alter daily job functions. We submit the notification 90 days before the Phase 2 banking go-live, detailing what changes (new CRM system), what stays the same (core banking FIS Horizon unchanged), and what training is provided. The training plan includes 40 hours of instructor-led Salesforce training per banking staff member, a 2-week parallel-run period where both Dynamics and Salesforce are available, and a dedicated support channel during the first 30 days post-cutover. The union consultation does not block the migration but requires documented good-faith engagement, and skipping it risks a grievance that could delay adoption.

Data Migration and Archival (D3)

Q26: Requirement 36 says migrate 1.2 TB of SharePoint banking documents. Are you migrating or just surfacing them?

Migrating. Surfacing via Files Connect alone does not satisfy Req 36, which calls for documents to be migrated to a solution accessible from client records, with metadata tagging by client, document type, and branch. The target store is AWS S3 with object-lock (WORM) enabled for SEC Rule 17a-4 compliance — S3 costs an order of magnitude less per GB than Salesforce file storage, which is also why I am not pushing 1.2 TB into native ContentDocument. MuleSoft runs a one-time parallelised transfer from SharePoint Online to S3 during Phase 2, preserves the content-type taxonomy as metadata, hashes files on both ends for integrity, and writes a Document_Metadata__c custom object record plus a ContentDocumentLink row pointing to the matching Person Account or Financial Account. Salesforce Files Connect then exposes the S3 store as if the files lived on the record. SharePoint is decommissioned as a document store at the end of Phase 2. Total migration window is roughly 8-10 weeks running in parallel with banking console build.

Q27: The wealth org already has a partial FSC managed-package implementation. How do you handle the data model migration to FSC Core?

The current org has the managed package activated (Person Account model and basic FinServ__FinancialAccount__c) but never fully configured. A greenfield build in 2025-2026 should run on FSC Core standard objects (FinancialAccount, FinancialAccountParty, AccountAccountRelation) because that is where all new FSC features, Agentforce capabilities, and roadmap investments live. In Phase 0, we migrate any data on the managed-package objects to the Core standard objects: extract records via Bulk API, transform field names (DataWeave in MuleSoft), insert into the Core objects, and rewire any custom automations and integrations to reference the new API names. Running both models in parallel is an explicit anti-goal — the documentation warns that when standard Financial Account objects are enabled alongside the managed package, both models are visible and users get confused about which is authoritative. We pick FSC Core, migrate the data, and retire the managed-package metadata from production after validation.

Q28: 12M activities, 78% storage, plus 3 years of Dynamics activities migrating in. What is your retention plan?

Three-tier strategy. Hot tier (0-18 months): active Task and Event records stay in standard objects. Warm tier (18-24 months): Batch Apex archives to an Activity_Archive__b Big Object with a composite index of (AccountId, ActivityDate, Id) — single-account lookback is fast, cross-account aggregation goes through Bulk API 2.0 extracts or CRM Analytics. Cold tier (24 months+): nightly offload from Big Object to AWS S3 via MuleSoft and Salesforce Backup for the full 7-year SEC/FINRA window. A MuleSoft lookup API pulls matching S3 records into an External_Activity_Archive__x Salesforce Connect external object on demand for compliance queries. The Dynamics activities arriving in Phase 2 land directly in the warm tier because they are already 1-3 years old, which avoids bloating hot storage at migration cut-over. This keeps total storage utilisation under 90% across the program.

Q29: Can you confirm FINRA Rule 4511 supervision actually works on the Experience Cloud secure messaging channel?

Yes, but not through the Messaging objects alone. MessagingSession and MessagingEndUser hold session metadata that compliance can query via SOQL, but the actual message content sits in the off-platform conversation store and is not available through standard SOQL or reports. For supervision and examiner response, the architecture runs two parallel retention paths. First, a MuleSoft connector calls the Conversation Data API nightly to export completed conversations into Smarsh, where the 7-year policy and supervisory review workflow already live — Smarsh remains the primary system of record for regulatory search and the 48-hour examiner production window. Second, a Data 360 (formerly Data Cloud) ingestion stream subscribes to the Messaging Conversation data kit so conversation content is replicated into a Data 360 data lake object, giving compliance a Salesforce-native search surface via the Data 360 query API. Saying “secure messaging is searchable by compliance” without specifying Conversation Data API or Data 360 sync is a hand-wave that does not survive a judge challenge.

Question Categorization

Domain	Questions
D1 System Architecture	Q1, Q2, Q3, Q19, Q20, Q22
D2 Security	Q4, Q5, Q6, Q16, Q17, Q18
D3 Data	Q7, Q8, Q21, Q26, Q27, Q28
D4 Solution Architecture	Q15
D5 Integration	Q9, Q10, Q23, Q24, Q29
D6 Dev Lifecycle	Q11, Q12, Q13, Q25
D7 Communication	Q14

Q&A Survival Rules

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

Related Topics

• Case Study 01 Solution
• Presentation Notes
• 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.